[gentoo-user] Unwelcomed non-native language support

[gentoo-user] Unwelcomed non-native language support

[gevisz]

In my everyday work at the computer, I read
and type at three or even four different languages.

However, I do want to have all program menues
and system messages only in English.

So, when I found out that it can be achieved by
setting -nls USE flag at my make.conf file, I did
it, recompiled the system and for a few weeks
enjoyed the full control of my Gentoo system.

(As far as I can remember the gettext package
was successfully depcleaned from my Gentoo
system just after that.)

However, after those few weeks (and some system
updates), I have noticed that my system started
to translate some "system" messages into one of
the languages I use but which is not my native language.

Moreover, running
$ equery depends gettext
I get about two fullscreens of packages that supposedly
depend on gettext. Nevertheless, in all of them the -nls
USE flag is either unset or absent.

I have tried to depclean the gettext package from my
system once again but portage just ignored my
$ emerge --depclean gettext
command.

I think that it is some kind of a bug in the portage tree:
when I set -nls USE flag globally, I do expect that the "system"
messages will appear in English only and will not be translated
in any other language, but the system understands that as
I would have asked for a "non-native" language support.

Of course, this is not my main problem in this life, but every
time I get the "system" messages translated into my non-native
language, I feel as I get a reminder that I do not have a full
control of my Gentoo system.

So, my questions are:
1.  Is it a bug?
2. How can I get rid of those unwelcomed translations in the right way.

Re: [gentoo-user] Unwelcomed non-native language support

[Volker Armin Hemmann]

Am 28.05.2015 um 17:35 schrieb gevisz:
> In my everyday work at the computer, I read
> and type at three or even four different languages.
>
> However, I do want to have all program menues
> and system messages only in English.
>
> So, when I found out that it can be achieved by
> setting -nls USE flag at my make.conf file, I did
> it, recompiled the system and for a few weeks
> enjoyed the full control of my Gentoo system.
>
> (As far as I can remember the gettext package
> was successfully depcleaned from my Gentoo
> system just after that.)
>
> However, after those few weeks (and some system
> updates), I have noticed that my system started
> to translate some "system" messages into one of
> the languages I use but which is not my native language.
>
> Moreover, running
> $ equery depends gettext
> I get about two fullscreens of packages that supposedly
> depend on gettext. Nevertheless, in all of them the -nls
> USE flag is either unset or absent.
>
> I have tried to depclean the gettext package from my
> system once again but portage just ignored my
> $ emerge --depclean gettext
> command.
>
> I think that it is some kind of a bug in the portage tree:
> when I set -nls USE flag globally, I do expect that the "system"
> messages will appear in English only and will not be translated
> in any other language, but the system understands that as
> I would have asked for a "non-native" language support.
>
> Of course, this is not my main problem in this life, but every
> time I get the "system" messages translated into my non-native
> language, I feel as I get a reminder that I do not have a full
> control of my Gentoo system.
>
> So, my questions are:
> 1.  Is it a bug?
> 2. How can I get rid of those unwelcomed translations in the right way.
>
>

1. if a package hard depends on gettext, you can fiddle around with
useflags as much as you want, it won't change. Not a bug. Just the way
it is.

2. environment variables. Set them. LANG, LANGUAGE and of course LC_ALL

Re: [gentoo-user] Unwelcomed non-native language support

[Mike Gilbert]

On Thu, May 28, 2015 at 6:41 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am 28.05.2015 um 17:35 schrieb gevisz:
>> In my everyday work at the computer, I read
>> and type at three or even four different languages.
>>
>> However, I do want to have all program menues
>> and system messages only in English.
>>
>> So, when I found out that it can be achieved by
>> setting -nls USE flag at my make.conf file, I did
>> it, recompiled the system and for a few weeks
>> enjoyed the full control of my Gentoo system.
>>
>> (As far as I can remember the gettext package
>> was successfully depcleaned from my Gentoo
>> system just after that.)
>>
>> However, after those few weeks (and some system
>> updates), I have noticed that my system started
>> to translate some "system" messages into one of
>> the languages I use but which is not my native language.
>>
>> Moreover, running
>> $ equery depends gettext
>> I get about two fullscreens of packages that supposedly
>> depend on gettext. Nevertheless, in all of them the -nls
>> USE flag is either unset or absent.
>>
>> I have tried to depclean the gettext package from my
>> system once again but portage just ignored my
>> $ emerge --depclean gettext
>> command.
>>
>> I think that it is some kind of a bug in the portage tree:
>> when I set -nls USE flag globally, I do expect that the "system"
>> messages will appear in English only and will not be translated
>> in any other language, but the system understands that as
>> I would have asked for a "non-native" language support.
>>
>> Of course, this is not my main problem in this life, but every
>> time I get the "system" messages translated into my non-native
>> language, I feel as I get a reminder that I do not have a full
>> control of my Gentoo system.
>>
>> So, my questions are:
>> 1.  Is it a bug?
>> 2. How can I get rid of those unwelcomed translations in the right way.
>>
>>
>
> 1. if a package hard depends on gettext, you can fiddle around with
> useflags as much as you want, it won't change. Not a bug. Just the way
> it is.

Sometimes it is a bug and the ebuild doesn't need gettext
unconditionally. It takes some expertise to figure that out, however.

> 2. environment variables. Set them. LANG, LANGUAGE and of course LC_ALL
>

I would suggest setting LANG=foo_BAR.UTF-8 and
LC_MESSAGES=en_US.UTF-8. Where foo and BAR are your native language
and locale.

Re: [gentoo-user] Unwelcomed non-native language support

[Gevisz]

On Fri, 29 May 2015 00:41:08 +0200 Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> Am 28.05.2015 um 17:35 schrieb gevisz:
> > In my everyday work at the computer, I read
> > and type at three or even four different languages.
> >
> > However, I do want to have all program menues
> > and system messages only in English.
> >
> > So, when I found out that it can be achieved by
> > setting -nls USE flag at my make.conf file, I did
> > it, recompiled the system and for a few weeks
> > enjoyed the full control of my Gentoo system.
> >
> > (As far as I can remember the gettext package
> > was successfully depcleaned from my Gentoo
> > system just after that.)
> >
> > However, after those few weeks (and some system
> > updates), I have noticed that my system started
> > to translate some "system" messages into one of
> > the languages I use but which is not my native language.
> >
> > Moreover, running
> > $ equery depends gettext
> > I get about two fullscreens of packages that supposedly
> > depend on gettext. Nevertheless, in all of them the -nls
> > USE flag is either unset or absent.
> >
> > I have tried to depclean the gettext package from my
> > system once again but portage just ignored my
> > $ emerge --depclean gettext
> > command.
> >
> > I think that it is some kind of a bug in the portage tree:
> > when I set -nls USE flag globally, I do expect that the "system"
> > messages will appear in English only and will not be translated
> > in any other language, but the system understands that as
> > I would have asked for a "non-native" language support.
> >
> > Of course, this is not my main problem in this life, but every
> > time I get the "system" messages translated into my non-native
> > language, I feel as I get a reminder that I do not have a full
> > control of my Gentoo system.
> >
> > So, my questions are:
> > 1.  Is it a bug?
> > 2. How can I get rid of those unwelcomed translations in the right way.
> >
> 
> 1. If a package hard depends on gettext, you can fiddle around with
> useflags as much as you want, it won't change. Not a bug. Just the way
> it is.

If a package hard depend on gettext, it is a bug, IMHO.
 
> 2. Environment variables. Set them. LANG, LANGUAGE and of course LC_ALL

$ echo $LANG
en_US.UTF-8
$ echo $LANGUAGE
                          %%% This environment variable is not set
$ echo $LC_ALL
                          %%% This environment variable is not set
 
Why the system suddenly decided that my native language is one of
the easten-europien ones, then?

And a month or two ago, all the system messages was in English
with exactly the same evironment variables setting. (And packages
did not hard-depend on gettext.) Strange.

Re: [gentoo-user] Unwelcomed non-native language support

[Gevisz]

On Thu, 28 May 2015 20:07:55 -0400 Mike Gilbert <floppym@gentoo.org> wrote:

> On Thu, May 28, 2015 at 6:41 PM, Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
> > Am 28.05.2015 um 17:35 schrieb gevisz:
> >> In my everyday work at the computer, I read
> >> and type at three or even four different languages.
> >>
> >> However, I do want to have all program menues
> >> and system messages only in English.
> >>
> >> So, when I found out that it can be achieved by
> >> setting -nls USE flag at my make.conf file, I did
> >> it, recompiled the system and for a few weeks
> >> enjoyed the full control of my Gentoo system.
> >>
> >> (As far as I can remember the gettext package
> >> was successfully depcleaned from my Gentoo
> >> system just after that.)
> >>
> >> However, after those few weeks (and some system
> >> updates), I have noticed that my system started
> >> to translate some "system" messages into one of
> >> the languages I use but which is not my native language.
> >>
> >> Moreover, running
> >> $ equery depends gettext
> >> I get about two fullscreens of packages that supposedly
> >> depend on gettext. Nevertheless, in all of them the -nls
> >> USE flag is either unset or absent.
> >>
> >> I have tried to depclean the gettext package from my
> >> system once again but portage just ignored my
> >> $ emerge --depclean gettext
> >> command.
> >>
> >> I think that it is some kind of a bug in the portage tree:
> >> when I set -nls USE flag globally, I do expect that the "system"
> >> messages will appear in English only and will not be translated
> >> in any other language, but the system understands that as
> >> I would have asked for a "non-native" language support.
> >>
> >> Of course, this is not my main problem in this life, but every
> >> time I get the "system" messages translated into my non-native
> >> language, I feel as I get a reminder that I do not have a full
> >> control of my Gentoo system.
> >>
> >> So, my questions are:
> >> 1.  Is it a bug?
> >> 2. How can I get rid of those unwelcomed translations in the right way.
> >>
> >>
> >
> > 1. if a package hard depends on gettext, you can fiddle around with
> > useflags as much as you want, it won't change. Not a bug. Just the way
> > it is.
> 
> Sometimes it is a bug and the ebuild doesn't need gettext
> unconditionally. It takes some expertise to figure that out, however.

I also think so.

> > 2. environment variables. Set them. LANG, LANGUAGE and of course LC_ALL
> >
> 
> I would suggest setting LANG=foo_BAR.UTF-8 and
> LC_MESSAGES=en_US.UTF-8. Where foo and BAR are your native language
> and locale.

I have
# set LC_MESSAGES=en_US.UTF-8
but it have not changed anything.

Or shall I change it in some config files and reboot the system?

Re: [gentoo-user] Unwelcomed non-native language support

[Volker Armin Hemmann]

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

just set LANGUAGE and LC_ALL.

2015-05-29 6:35 GMT+02:00 Gevisz <gevisz@gmail.com>:

> On Thu, 28 May 2015 20:07:55 -0400 Mike Gilbert <floppym@gentoo.org>
> wrote:
>
> > On Thu, May 28, 2015 at 6:41 PM, Volker Armin Hemmann
> > <volkerarmin@googlemail.com> wrote:
> > > Am 28.05.2015 um 17:35 schrieb gevisz:
> > >> In my everyday work at the computer, I read
> > >> and type at three or even four different languages.
> > >>
> > >> However, I do want to have all program menues
> > >> and system messages only in English.
> > >>
> > >> So, when I found out that it can be achieved by
> > >> setting -nls USE flag at my make.conf file, I did
> > >> it, recompiled the system and for a few weeks
> > >> enjoyed the full control of my Gentoo system.
> > >>
> > >> (As far as I can remember the gettext package
> > >> was successfully depcleaned from my Gentoo
> > >> system just after that.)
> > >>
> > >> However, after those few weeks (and some system
> > >> updates), I have noticed that my system started
> > >> to translate some "system" messages into one of
> > >> the languages I use but which is not my native language.
> > >>
> > >> Moreover, running
> > >> $ equery depends gettext
> > >> I get about two fullscreens of packages that supposedly
> > >> depend on gettext. Nevertheless, in all of them the -nls
> > >> USE flag is either unset or absent.
> > >>
> > >> I have tried to depclean the gettext package from my
> > >> system once again but portage just ignored my
> > >> $ emerge --depclean gettext
> > >> command.
> > >>
> > >> I think that it is some kind of a bug in the portage tree:
> > >> when I set -nls USE flag globally, I do expect that the "system"
> > >> messages will appear in English only and will not be translated
> > >> in any other language, but the system understands that as
> > >> I would have asked for a "non-native" language support.
> > >>
> > >> Of course, this is not my main problem in this life, but every
> > >> time I get the "system" messages translated into my non-native
> > >> language, I feel as I get a reminder that I do not have a full
> > >> control of my Gentoo system.
> > >>
> > >> So, my questions are:
> > >> 1.  Is it a bug?
> > >> 2. How can I get rid of those unwelcomed translations in the right
> way.
> > >>
> > >>
> > >
> > > 1. if a package hard depends on gettext, you can fiddle around with
> > > useflags as much as you want, it won't change. Not a bug. Just the way
> > > it is.
> >
> > Sometimes it is a bug and the ebuild doesn't need gettext
> > unconditionally. It takes some expertise to figure that out, however.
>
> I also think so.
>
> > > 2. environment variables. Set them. LANG, LANGUAGE and of course LC_ALL
> > >
> >
> > I would suggest setting LANG=foo_BAR.UTF-8 and
> > LC_MESSAGES=en_US.UTF-8. Where foo and BAR are your native language
> > and locale.
>
> I have
> # set LC_MESSAGES=en_US.UTF-8
> but it have not changed anything.
>
> Or shall I change it in some config files and reboot the system?
>
>
>

[-- Attachment #2: Type: text/html, Size: 4232 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3050 bytes --]

On Friday 29 May 2015 05:24:49 Gevisz wrote:
> On Fri, 29 May 2015 00:41:08 +0200 Volker Armin Hemmann 
<volkerarmin@googlemail.com> wrote:
> > Am 28.05.2015 um 17:35 schrieb gevisz:
> > > In my everyday work at the computer, I read
> > > and type at three or even four different languages.
> > > 
> > > However, I do want to have all program menues
> > > and system messages only in English.
> > > 
> > > So, when I found out that it can be achieved by
> > > setting -nls USE flag at my make.conf file, I did
> > > it, recompiled the system and for a few weeks
> > > enjoyed the full control of my Gentoo system.
> > > 
> > > (As far as I can remember the gettext package
> > > was successfully depcleaned from my Gentoo
> > > system just after that.)
> > > 
> > > However, after those few weeks (and some system
> > > updates), I have noticed that my system started
> > > to translate some "system" messages into one of
> > > the languages I use but which is not my native language.
> > > 
> > > Moreover, running
> > > $ equery depends gettext
> > > I get about two fullscreens of packages that supposedly
> > > depend on gettext. Nevertheless, in all of them the -nls
> > > USE flag is either unset or absent.
> > > 
> > > I have tried to depclean the gettext package from my
> > > system once again but portage just ignored my
> > > $ emerge --depclean gettext
> > > command.
> > > 
> > > I think that it is some kind of a bug in the portage tree:
> > > when I set -nls USE flag globally, I do expect that the "system"
> > > messages will appear in English only and will not be translated
> > > in any other language, but the system understands that as
> > > I would have asked for a "non-native" language support.
> > > 
> > > Of course, this is not my main problem in this life, but every
> > > time I get the "system" messages translated into my non-native
> > > language, I feel as I get a reminder that I do not have a full
> > > control of my Gentoo system.
> > > 
> > > So, my questions are:
> > > 1.  Is it a bug?
> > > 2. How can I get rid of those unwelcomed translations in the right way.
> > 
> > 1. If a package hard depends on gettext, you can fiddle around with
> > useflags as much as you want, it won't change. Not a bug. Just the way
> > it is.
> 
> If a package hard depend on gettext, it is a bug, IMHO.
> 
> > 2. Environment variables. Set them. LANG, LANGUAGE and of course LC_ALL
> 
> $ echo $LANG
> en_US.UTF-8
> $ echo $LANGUAGE
>                           %%% This environment variable is not set
> $ echo $LC_ALL
>                           %%% This environment variable is not set
> 
> Why the system suddenly decided that my native language is one of
> the easten-europien ones, then?
> 
> And a month or two ago, all the system messages was in English
> with exactly the same evironment variables setting. (And packages
> did not hard-depend on gettext.) Strange.

Do you get anything unexpected when you run 'locale'?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-29 17:46 GMT+03:00 Mick <michaelkintzios@gmail.com>:
> On Friday 29 May 2015 05:24:49 Gevisz wrote:
>> On Fri, 29 May 2015 00:41:08 +0200 Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
>> > Am 28.05.2015 um 17:35 schrieb gevisz:
>> > > In my everyday work at the computer, I read
>> > > and type at three or even four different languages.
>> > >
>> > > However, I do want to have all program menues
>> > > and system messages only in English.
>> > >
>> > > So, when I found out that it can be achieved by
>> > > setting -nls USE flag at my make.conf file, I did
>> > > it, recompiled the system and for a few weeks
>> > > enjoyed the full control of my Gentoo system.
>> > >
>> > > (As far as I can remember the gettext package
>> > > was successfully depcleaned from my Gentoo
>> > > system just after that.)
>> > >
>> > > However, after those few weeks (and some system
>> > > updates), I have noticed that my system started
>> > > to translate some "system" messages into one of
>> > > the languages I use but which is not my native language.
>> > >
>> > > Moreover, running
>> > > $ equery depends gettext
>> > > I get about two fullscreens of packages that supposedly
>> > > depend on gettext. Nevertheless, in all of them the -nls
>> > > USE flag is either unset or absent.
>> > >
>> > > I have tried to depclean the gettext package from my
>> > > system once again but portage just ignored my
>> > > $ emerge --depclean gettext
>> > > command.
>> > >
>> > > I think that it is some kind of a bug in the portage tree:
>> > > when I set -nls USE flag globally, I do expect that the "system"
>> > > messages will appear in English only and will not be translated
>> > > in any other language, but the system understands that as
>> > > I would have asked for a "non-native" language support.
>> > >
>> > > Of course, this is not my main problem in this life, but every
>> > > time I get the "system" messages translated into my non-native
>> > > language, I feel as I get a reminder that I do not have a full
>> > > control of my Gentoo system.
>> > >
>> > > So, my questions are:
>> > > 1.  Is it a bug?
>> > > 2. How can I get rid of those unwelcomed translations in the right way.
>> >
>> > 1. If a package hard depends on gettext, you can fiddle around with
>> > useflags as much as you want, it won't change. Not a bug. Just the way
>> > it is.
>>
>> If a package hard depend on gettext, it is a bug, IMHO.
>>
>> > 2. Environment variables. Set them. LANG, LANGUAGE and of course LC_ALL
>>
>> $ echo $LANG
>> en_US.UTF-8
>> $ echo $LANGUAGE
>>                           %%% This environment variable is not set
>> $ echo $LC_ALL
>>                           %%% This environment variable is not set
>>
>> Why the system suddenly decided that my native language is one of
>> the easten-europien ones, then?
>>
>> And a month or two ago, all the system messages was in English
>> with exactly the same evironment variables setting. (And packages
>> did not hard-depend on gettext.) Strange.
>
> Do you get anything unexpected when you run 'locale'?

Nothing. (Thank you for your question.)

I have just re-read the Gentoo Localization Guide
(https://wiki.gentoo.org/wiki/Localization/Guide)
and checked what I have in my /etc/env.d/02locale
file: every possible option, except for LC_COLLATE
and LC_ALL, is set to en_US.UTF-8. Here is its full
content:

LANG="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"

Here is what I get from
$ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=C
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

I am almost giving up on this issue.

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-29 10:08 GMT+03:00 Volker Armin Hemmann <volkerarmin@googlemail.com>:
> just set LANGUAGE and LC_ALL.

Thank you for your suggestion. I have just re-read
the Gentoo Localization Guide. It does not mention
the LANGUAGE environment variable and do not
recommend to set LC_ALL. All the other is done as
described in the Gentoo Localization Guide. Every
possible option, except for LC_COLLATE and LC_ALL,
in my /etc/env.d/02locale file is set to en_US.UTF-8
as follows:
LANG="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"

Firefox is compiled without any linguas set.
NLS support disabled globally in make.conf.
And still, while right-clicking on youtube videos
in firefox, I get menu in one of the easten-europian
languages. :(

Just about two or three weeks ago, with the same
configuration settings, I got the same menu in English.

Re: [gentoo-user] Unwelcomed non-native language support

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1563 bytes --]

On Friday 29 May 2015 17:20:13 gevisz wrote:
> 2015-05-29 17:46 GMT+03:00 Mick <michaelkintzios@gmail.com>:

> > Do you get anything unexpected when you run 'locale'?
> 
> Nothing. (Thank you for your question.)
> 
> I have just re-read the Gentoo Localization Guide
> (https://wiki.gentoo.org/wiki/Localization/Guide)
> and checked what I have in my /etc/env.d/02locale
> file: every possible option, except for LC_COLLATE
> and LC_ALL, is set to en_US.UTF-8. Here is its full
> content:
> 
> LANG="en_US.UTF-8"
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE=C
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"

You probably don't need all these.  Mine are:

LANG="en_GB.UTF-8"
LC_TIME="POSIX"
LC_COLLATE="C"

The rest are inherited from $LANG.

> Here is what I get from
> $ locale
> LANG=en_US.UTF-8
> LC_CTYPE=en_US.UTF-8
> LC_NUMERIC=en_US.UTF-8
> LC_TIME=en_US.UTF-8
> LC_COLLATE=C
> LC_MONETARY=en_US.UTF-8
> LC_MESSAGES=en_US.UTF-8
> LC_PAPER=en_US.UTF-8
> LC_NAME=en_US.UTF-8
> LC_ADDRESS=en_US.UTF-8
> LC_TELEPHONE=en_US.UTF-8
> LC_MEASUREMENT=en_US.UTF-8
> LC_IDENTIFICATION=en_US.UTF-8
> LC_ALL=
> 
> I am almost giving up on this issue.

Hmm ... this is rather odd.  Just in case, you don't have in addition any LANG 
or LC_*  entries in your .bashrc?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

Am Fri, 29 May 2015 19:34:03 +0300
schrieb gevisz <gevisz@gmail.com>:

> Firefox is compiled without any linguas set.
> NLS support disabled globally in make.conf.
> And still, while right-clicking on youtube videos
> in firefox, I get menu in one of the easten-europian
> languages. :(

This may very well be outside of the control of the browser.  I don't know for
sure how it works, but as I understand it, websites *can* determine your
location (or try to) and adapt themselves accordingly.  For example, I'm in
northern Germany and in the past I would sometimes get the dutch localisation
of youtube, and IMDB always shows me the terrible German titles of movies, even
in links in English comments.  That's just bad website design, at least in
my opinion.

Actually, after I wrote that, I decided to look in the Firefox settings, and
presto: you can set the preferred locales for websites (under the "content"
tab, or whatever it's called in English)! That fixed IMDB for me, maybe it'll
work for you?

I don't think you've answered this yet: is this the only situation where you
get the wrong locale, or does it happen in *native* applications, too?

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-29 19:36 GMT+03:00 Mick <michaelkintzios@gmail.com>:
> On Friday 29 May 2015 17:20:13 gevisz wrote:
>> 2015-05-29 17:46 GMT+03:00 Mick <michaelkintzios@gmail.com>:
>
>> > Do you get anything unexpected when you run 'locale'?
>>
>> Nothing. (Thank you for your question.)
>>
>> I have just re-read the Gentoo Localization Guide
>> (https://wiki.gentoo.org/wiki/Localization/Guide)
>> and checked what I have in my /etc/env.d/02locale
>> file: every possible option, except for LC_COLLATE
>> and LC_ALL, is set to en_US.UTF-8. Here is its full
>> content:
>>
>> LANG="en_US.UTF-8"
>> LC_CTYPE="en_US.UTF-8"
>> LC_NUMERIC="en_US.UTF-8"
>> LC_TIME="en_US.UTF-8"
>> LC_COLLATE=C
>> LC_MONETARY="en_US.UTF-8"
>> LC_MESSAGES="en_US.UTF-8"
>> LC_PAPER="en_US.UTF-8"
>> LC_NAME="en_US.UTF-8"
>> LC_ADDRESS="en_US.UTF-8"
>> LC_TELEPHONE="en_US.UTF-8"
>> LC_MEASUREMENT="en_US.UTF-8"
>> LC_IDENTIFICATION="en_US.UTF-8"
>
> You probably don't need all these.  Mine are:
>
> LANG="en_GB.UTF-8"
> LC_TIME="POSIX"
> LC_COLLATE="C"
>
> The rest are inherited from $LANG.
>
>> Here is what I get from
>> $ locale
>> LANG=en_US.UTF-8
>> LC_CTYPE=en_US.UTF-8
>> LC_NUMERIC=en_US.UTF-8
>> LC_TIME=en_US.UTF-8
>> LC_COLLATE=C
>> LC_MONETARY=en_US.UTF-8
>> LC_MESSAGES=en_US.UTF-8
>> LC_PAPER=en_US.UTF-8
>> LC_NAME=en_US.UTF-8
>> LC_ADDRESS=en_US.UTF-8
>> LC_TELEPHONE=en_US.UTF-8
>> LC_MEASUREMENT=en_US.UTF-8
>> LC_IDENTIFICATION=en_US.UTF-8
>> LC_ALL=
>>
>> I am almost giving up on this issue.
>
> Hmm ... this is rather odd.  Just in case, you don't have in addition any LANG
> or LC_*  entries in your .bashrc?

No. Looked there as well.

Now, I am going to forcefully unmerge the gettext package.
Will report the results later.

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-29 10:08 GMT+03:00 Volker Armin Hemmann <volkerarmin@googlemail.com>:
> just set LANGUAGE and LC_ALL.

This does not work. Just tried to be sure.

> 2015-05-29 6:35 GMT+02:00 Gevisz <gevisz@gmail.com>:
>>
>> On Thu, 28 May 2015 20:07:55 -0400 Mike Gilbert <floppym@gentoo.org>
>> wrote:
>>
>> > On Thu, May 28, 2015 at 6:41 PM, Volker Armin Hemmann
>> > <volkerarmin@googlemail.com> wrote:
>> > > Am 28.05.2015 um 17:35 schrieb gevisz:
>> > >> In my everyday work at the computer, I read
>> > >> and type at three or even four different languages.
>> > >>
>> > >> However, I do want to have all program menues
>> > >> and system messages only in English.
>> > >>
>> > >> So, when I found out that it can be achieved by
>> > >> setting -nls USE flag at my make.conf file, I did
>> > >> it, recompiled the system and for a few weeks
>> > >> enjoyed the full control of my Gentoo system.
>> > >>
>> > >> (As far as I can remember the gettext package
>> > >> was successfully depcleaned from my Gentoo
>> > >> system just after that.)
>> > >>
>> > >> However, after those few weeks (and some system
>> > >> updates), I have noticed that my system started
>> > >> to translate some "system" messages into one of
>> > >> the languages I use but which is not my native language.
>> > >>
>> > >> Moreover, running
>> > >> $ equery depends gettext
>> > >> I get about two fullscreens of packages that supposedly
>> > >> depend on gettext. Nevertheless, in all of them the -nls
>> > >> USE flag is either unset or absent.
>> > >>
>> > >> I have tried to depclean the gettext package from my
>> > >> system once again but portage just ignored my
>> > >> $ emerge --depclean gettext
>> > >> command.
>> > >>
>> > >> I think that it is some kind of a bug in the portage tree:
>> > >> when I set -nls USE flag globally, I do expect that the "system"
>> > >> messages will appear in English only and will not be translated
>> > >> in any other language, but the system understands that as
>> > >> I would have asked for a "non-native" language support.
>> > >>
>> > >> Of course, this is not my main problem in this life, but every
>> > >> time I get the "system" messages translated into my non-native
>> > >> language, I feel as I get a reminder that I do not have a full
>> > >> control of my Gentoo system.
>> > >>
>> > >> So, my questions are:
>> > >> 1.  Is it a bug?
>> > >> 2. How can I get rid of those unwelcomed translations in the right
>> > >> way.
>> > >>
>> > >>
>> > >
>> > > 1. if a package hard depends on gettext, you can fiddle around with
>> > > useflags as much as you want, it won't change. Not a bug. Just the way
>> > > it is.
>> >
>> > Sometimes it is a bug and the ebuild doesn't need gettext
>> > unconditionally. It takes some expertise to figure that out, however.
>>
>> I also think so.
>>
>> > > 2. environment variables. Set them. LANG, LANGUAGE and of course
>> > > LC_ALL
>> > >
>> >
>> > I would suggest setting LANG=foo_BAR.UTF-8 and
>> > LC_MESSAGES=en_US.UTF-8. Where foo and BAR are your native language
>> > and locale.
>>
>> I have
>> # set LC_MESSAGES=en_US.UTF-8
>> but it have not changed anything.
>>
>> Or shall I change it in some config files and reboot the system?
>>
>>
>

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-29 21:45 GMT+03:00 gevisz <gevisz@gmail.com>:
> 2015-05-29 19:36 GMT+03:00 Mick <michaelkintzios@gmail.com>:
>> On Friday 29 May 2015 17:20:13 gevisz wrote:
>>> 2015-05-29 17:46 GMT+03:00 Mick <michaelkintzios@gmail.com>:
>>
>>> > Do you get anything unexpected when you run 'locale'?
>>>
>>> Nothing. (Thank you for your question.)
>>>
>>> I have just re-read the Gentoo Localization Guide
>>> (https://wiki.gentoo.org/wiki/Localization/Guide)
>>> and checked what I have in my /etc/env.d/02locale
>>> file: every possible option, except for LC_COLLATE
>>> and LC_ALL, is set to en_US.UTF-8. Here is its full
>>> content:
>>>
>>> LANG="en_US.UTF-8"
>>> LC_CTYPE="en_US.UTF-8"
>>> LC_NUMERIC="en_US.UTF-8"
>>> LC_TIME="en_US.UTF-8"
>>> LC_COLLATE=C
>>> LC_MONETARY="en_US.UTF-8"
>>> LC_MESSAGES="en_US.UTF-8"
>>> LC_PAPER="en_US.UTF-8"
>>> LC_NAME="en_US.UTF-8"
>>> LC_ADDRESS="en_US.UTF-8"
>>> LC_TELEPHONE="en_US.UTF-8"
>>> LC_MEASUREMENT="en_US.UTF-8"
>>> LC_IDENTIFICATION="en_US.UTF-8"
>>
>> You probably don't need all these.  Mine are:
>>
>> LANG="en_GB.UTF-8"
>> LC_TIME="POSIX"
>> LC_COLLATE="C"
>>
>> The rest are inherited from $LANG.
>>
>>> Here is what I get from
>>> $ locale
>>> LANG=en_US.UTF-8
>>> LC_CTYPE=en_US.UTF-8
>>> LC_NUMERIC=en_US.UTF-8
>>> LC_TIME=en_US.UTF-8
>>> LC_COLLATE=C
>>> LC_MONETARY=en_US.UTF-8
>>> LC_MESSAGES=en_US.UTF-8
>>> LC_PAPER=en_US.UTF-8
>>> LC_NAME=en_US.UTF-8
>>> LC_ADDRESS=en_US.UTF-8
>>> LC_TELEPHONE=en_US.UTF-8
>>> LC_MEASUREMENT=en_US.UTF-8
>>> LC_IDENTIFICATION=en_US.UTF-8
>>> LC_ALL=
>>>
>>> I am almost giving up on this issue.
>>
>> Hmm ... this is rather odd.  Just in case, you don't have in addition any LANG
>> or LC_*  entries in your .bashrc?
>
> No. Looked there as well.
>
> Now, I am going to forcefully unmerge the gettext package.
> Will report the results later.

Reporting: after forcefully unmerging the gettext package,
shutting down the system and booting it anew, I still get
the described above menu in Firefox in one of the easten-european
languages.

I am killed! Completely.

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-29 20:34 GMT+03:00 Marc Joliet <marcec@gmx.de>:
> Am Fri, 29 May 2015 19:34:03 +0300
> schrieb gevisz <gevisz@gmail.com>:
>
>> Firefox is compiled without any linguas set.
>> NLS support disabled globally in make.conf.
>> And still, while right-clicking on youtube videos
>> in firefox, I get menu in one of the easten-europian
>> languages. :(
>
> This may very well be outside of the control of the browser.  I don't know for
> sure how it works, but as I understand it, websites *can* determine your
> location (or try to) and adapt themselves accordingly.

May be. But I have just tried the same from Google Chrome
and got the same menu in English.

>  For example, I'm in northern Germany and in the past I would
> sometimes get the dutch localisation of youtube, and IMDB
> always shows me the terrible German titles of movies, even
> in links in English comments.  That's just bad website design,
> at least in my opinion.

But why a change of a browser solves the issue?

> Actually, after I wrote that, I decided to look in the Firefox settings, and
> presto: you can set the preferred locales for websites (under the "content"
> tab, or whatever it's called in English)! That fixed IMDB for me, maybe it'll
> work for you?

If you mean Firefox Preferences > Content > Languages > Choose...,
I have only the English language there.

May be I should dig into about:config, but from the first look
I could not find there anything related to my problem either.

> I don't think you've answered this yet: is this the only situation where you
> get the wrong locale, or does it happen in *native* applications, too?

Yes, this is the only situation I met. However the set of applications I use
is quite limited.

> Marc Joliet
> --
> "People who think they know everything really annoy those of us who know we
> don't" - Bjarne Stroustrup

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-29 23:33 GMT+03:00 gevisz <gevisz@gmail.com>:
> 2015-05-29 21:45 GMT+03:00 gevisz <gevisz@gmail.com>:
>> 2015-05-29 19:36 GMT+03:00 Mick <michaelkintzios@gmail.com>:
>>> On Friday 29 May 2015 17:20:13 gevisz wrote:
>>>> 2015-05-29 17:46 GMT+03:00 Mick <michaelkintzios@gmail.com>:
>>>
>>>> > Do you get anything unexpected when you run 'locale'?
>>>>
>>>> Nothing. (Thank you for your question.)
>>>>
>>>> I have just re-read the Gentoo Localization Guide
>>>> (https://wiki.gentoo.org/wiki/Localization/Guide)
>>>> and checked what I have in my /etc/env.d/02locale
>>>> file: every possible option, except for LC_COLLATE
>>>> and LC_ALL, is set to en_US.UTF-8. Here is its full
>>>> content:
>>>>
>>>> LANG="en_US.UTF-8"
>>>> LC_CTYPE="en_US.UTF-8"
>>>> LC_NUMERIC="en_US.UTF-8"
>>>> LC_TIME="en_US.UTF-8"
>>>> LC_COLLATE=C
>>>> LC_MONETARY="en_US.UTF-8"
>>>> LC_MESSAGES="en_US.UTF-8"
>>>> LC_PAPER="en_US.UTF-8"
>>>> LC_NAME="en_US.UTF-8"
>>>> LC_ADDRESS="en_US.UTF-8"
>>>> LC_TELEPHONE="en_US.UTF-8"
>>>> LC_MEASUREMENT="en_US.UTF-8"
>>>> LC_IDENTIFICATION="en_US.UTF-8"
>>>
>>> You probably don't need all these.  Mine are:
>>>
>>> LANG="en_GB.UTF-8"
>>> LC_TIME="POSIX"
>>> LC_COLLATE="C"
>>>
>>> The rest are inherited from $LANG.
>>>
>>>> Here is what I get from
>>>> $ locale
>>>> LANG=en_US.UTF-8
>>>> LC_CTYPE=en_US.UTF-8
>>>> LC_NUMERIC=en_US.UTF-8
>>>> LC_TIME=en_US.UTF-8
>>>> LC_COLLATE=C
>>>> LC_MONETARY=en_US.UTF-8
>>>> LC_MESSAGES=en_US.UTF-8
>>>> LC_PAPER=en_US.UTF-8
>>>> LC_NAME=en_US.UTF-8
>>>> LC_ADDRESS=en_US.UTF-8
>>>> LC_TELEPHONE=en_US.UTF-8
>>>> LC_MEASUREMENT=en_US.UTF-8
>>>> LC_IDENTIFICATION=en_US.UTF-8
>>>> LC_ALL=
>>>>
>>>> I am almost giving up on this issue.
>>>
>>> Hmm ... this is rather odd.  Just in case, you don't have in addition any LANG
>>> or LC_*  entries in your .bashrc?
>>
>> No. Looked there as well.
>>
>> Now, I am going to forcefully unmerge the gettext package.
>> Will report the results later.
>
> Reporting: after forcefully unmerging the gettext package,
> shutting down the system and booting it anew, I still get
> the described above menu in Firefox in one of the easten-european
> languages.

As I still had a suspicion that those non-Eglish entries in the Firefox
menu remain because of some cash issues, I have just launched another
instance of the Firefox browser using a separate profile.

Well, in a separate profile, the Firefox menu is in English while
in the default profile it is in a non-English language.

So, it could be a cash issue: I have unmerged the gettext while
running Firefox and so its substitutions could be left somewhere
in cash...

P.S. As I have already described it earlier, this issue with the Firefox
      menu is only related to the menu I get while right-clicking on
      a youtube video in Firefox.  (All the other menus is in English,
      as desired.)

Re: [gentoo-user] Unwelcomed non-native language support

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Am Sat, 30 May 2015 11:36:28 +0300
schrieb gevisz <gevisz@gmail.com>:

[...]
> As I still had a suspicion that those non-Eglish entries in the Firefox
> menu remain because of some cash issues, I have just launched another
> instance of the Firefox browser using a separate profile.
> 
> Well, in a separate profile, the Firefox menu is in English while
> in the default profile it is in a non-English language.
> 
> So, it could be a cash issue: I have unmerged the gettext while
> running Firefox and so its substitutions could be left somewhere
> in cash...
> 
> P.S. As I have already described it earlier, this issue with the Firefox
>       menu is only related to the menu I get while right-clicking on
>       a youtube video in Firefox.  (All the other menus is in English,
>       as desired.)

(Note: the word you are looking for is "cache".)

I strongly suspect that the application doing the translating doesn't even use
gettext.  Besides which, I'm surprised you're not getting crashes from
applications not finding the gettext libraries, which points to them not
actually using it.  You can use "emerge --depclean -pv gettext" to determine
which do.  In my case, firefox does *not* show up, despite me using nls
(neither does adobe-flash, in case you're using that).

(I also thought that maybe firefox bundles gettext, but the only references I
could find on developer.mozilla.org pertain to localising websites with php
and the like, and not to firefox-internal technologies.)

So it seems to me that gettext is a false lead and that the root of your problem
lies somewhere else.  This document shows how websites can localise their
content:
https://developer.mozilla.org/en-US/docs/Web_Localizability/Creating_localizable_web_applications.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[rhannek]

On 30/05/15 11:36, gevisz wrote:
>P.S. As I have already described it earlier, this issue with the Firefox
>      menu is only related to the menu I get while right-clicking on
>      a youtube video in Firefox.  (All the other menus is in English,
>      as desired.)
>

Have you checked the language settings at the bottom of the site? The
menu you get is from the site and not from firefox.

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 12:32 GMT+03:00 Marc Joliet <marcec@gmx.de>:
> Am Sat, 30 May 2015 11:36:28 +0300
> schrieb gevisz <gevisz@gmail.com>:
>
> [...]
>> As I still had a suspicion that those non-English entries in the Firefox
>> menu remain because of some cash issues, I have just launched another
>> instance of the Firefox browser using a separate profile.
>>
>> Well, in a separate profile, the Firefox menu is in English while
>> in the default profile it is in a non-English language.
>>
>> So, it could be a cash issue: I have unmerged the gettext while
>> running Firefox and so its substitutions could be left somewhere
>> in cash...
>>
>> P.S. As I have already described it earlier, this issue with the Firefox
>>       menu is only related to the menu I get while right-clicking on
>>       a youtube video in Firefox.  (All the other menus is in English,
>>       as desired.)
>
> (Note: the word you are looking for is "cache".)

So, it is from French.

When I learned it in high school, this word was not in our vocabulary. :-)

> I strongly suspect that the application doing the translating doesn't
> even use gettext.

May be, but I cannot think of a better explanation.

> Besides which, I'm surprised you're not getting crashes from
> applications not finding the gettext libraries, which points
> to them not actually using it.

Nothing crashed so far and this, in my view, proves that should not
be an obligatory dependency for any package in my wold file.

>  You can use "emerge --depclean -pv gettext" to determine which do.

$ emerge --depclean -pv gettext
--- Couldn't find 'gettext' to depclean.
>>> No packages selected for removal by depclean

However, running
# equery depends gettext
before forcefully unmerging the gettext package,
I got the following response:

 * These packages depend on gettext:
app-admin/abrt-2.0.12-r2 (>=sys-devel/gettext-0.17)
app-admin/gtkdiskfree-2.0.1-r1 (nls ? sys-devel/gettext)
app-arch/tar-1.27.1-r2 (nls ? >=sys-devel/gettext-0.10.35)
app-cdr/brasero-3.12.0 (sys-devel/gettext)
app-cdr/xfburn-0.5.2 (sys-devel/gettext)
app-crypt/gcr-3.14.0 (sys-devel/gettext)
app-crypt/gnupg-2.0.26-r3 (nls ? sys-devel/gettext)
app-crypt/libsecret-0.18 (sys-devel/gettext)
app-crypt/pinentry-0.9.0 (sys-devel/gettext)
app-editors/gvim-7.4.273 (nls ? sys-devel/gettext)
                             %%% Even gvim! And it definitely does not
crash without gettext.
app-editors/mousepad-0.3.0 (sys-devel/gettext)
app-editors/vim-7.4.273 (nls ? sys-devel/gettext)
app-emulation/wine-1.6.2 (nls ? sys-devel/gettext)
                         (nls ? >=sys-devel/gettext-0.18.3.2[abi_x86_32(-)])
app-i18n/enca-1.14-r2 (sys-devel/gettext)
app-misc/mc-4.8.13 (nls ? sys-devel/gettext)
app-misc/tracker-1.2.5 (>=sys-devel/gettext-0.17)
app-portage/eix-0.30.4 (nls ? sys-devel/gettext)
app-text/aspell-0.60.6.1-r1 (nls ? sys-devel/gettext)
app-text/dos2unix-6.0.6 (nls ? sys-devel/gettext)
app-text/enscript-1.6.6 (nls ? sys-devel/gettext)
app-text/evince-3.14.2 (sys-devel/gettext)
app-text/gnome-doc-utils-0.20.10-r1 (sys-devel/gettext)
app-text/hunspell-1.3.3 (sys-devel/gettext)
app-text/iso-codes-3.57 (sys-devel/gettext)
app-text/opensp-1.5.2-r3 (nls ? sys-devel/gettext)
app-text/recode-3.6_p20-r1 (nls ? sys-devel/gettext)
dev-lang/yasm-1.2.0-r1 (nls ? sys-devel/gettext)
dev-libs/atk-2.14.0 (nls ? sys-devel/gettext)
dev-libs/elfutils-0.158 (nls ? sys-devel/gettext)
dev-libs/gjs-1.42.0 (sys-devel/gettext)
dev-libs/glib-2.42.2 (>=sys-devel/gettext-0.11)
dev-libs/json-glib-1.0.2-r1 (>=sys-devel/gettext-0.18)
dev-libs/libcdio-0.92 (sys-devel/gettext)
dev-libs/libcdio-paranoia-0.90_p1-r1 (sys-devel/gettext)
dev-libs/libgpg-error-1.13 (nls ? sys-devel/gettext)
dev-libs/libpwquality-1.2.4 (>=sys-devel/gettext-0.18.2)
dev-libs/libreport-2.0.13-r1 (>=sys-devel/gettext-0.17)
dev-libs/popt-1.16-r2 (nls ? sys-devel/gettext)
dev-scheme/guile-1.8.8-r1 (sys-devel/gettext)
dev-util/dialog-1.2.20150225 (nls ? sys-devel/gettext)
dev-util/intltool-0.50.2-r1 (sys-devel/gettext)
dev-util/kbuild-0.1.9998_pre20131130 (sys-devel/gettext)
dev-vcs/git-2.3.6 (nls ? sys-devel/gettext)
gnome-base/dconf-0.22.0 (sys-devel/gettext)
gnome-base/gnome-desktop-3.14.2 (sys-devel/gettext)
gnome-base/gnome-keyring-3.14.0 (sys-devel/gettext)
gnome-base/gsettings-desktop-schemas-3.14.1 (sys-devel/gettext)
gnome-base/libgnome-keyring-3.12.0 (sys-devel/gettext)
gnome-base/nautilus-3.14.2-r1 (sys-devel/gettext)
gnome-extra/polkit-gnome-0.105-r1 (sys-devel/gettext)
gnome-extra/yelp-xsl-3.14.0 (sys-devel/gettext)
media-gfx/dcraw-9.24.4 (nls ? sys-devel/gettext)
media-gfx/exiv2-0.24-r1 (nls ? sys-devel/gettext)
media-gfx/gimp-2.8.14 (>=sys-devel/gettext-0.19)
media-gfx/graphviz-2.26.3-r4 (nls ? >=sys-devel/gettext-0.14.5)
media-libs/clutter-1.20.0 (>=sys-devel/gettext-0.17)
media-libs/clutter-gtk-1.6.0 (>=sys-devel/gettext-0.18)
media-libs/cogl-1.18.2-r1 (sys-devel/gettext)
media-libs/flac-1.3.1-r1 (!elibc_uclibc ? sys-devel/gettext)
media-libs/gst-plugins-bad-0.10.23-r2 (nls ? >=sys-devel/gettext-0.17)
media-libs/gst-plugins-bad-1.4.5 (nls ? >=sys-devel/gettext-0.17)
media-libs/gst-plugins-base-0.10.36-r2 (nls ? >=sys-devel/gettext-0.17)
media-libs/gst-plugins-base-1.4.5 (nls ? >=sys-devel/gettext-0.17)
media-libs/gst-plugins-good-0.10.31-r1 (nls ? >=sys-devel/gettext-0.17)
media-libs/gst-plugins-good-1.4.5 (nls ? >=sys-devel/gettext-0.17)
media-libs/gst-plugins-ugly-0.10.19-r1 (nls ? >=sys-devel/gettext-0.17)
media-libs/gst-plugins-ugly-1.4.5 (nls ? >=sys-devel/gettext-0.17)
media-libs/gstreamer-0.10.36-r2 (nls ? sys-devel/gettext)
media-libs/gstreamer-1.4.5 (nls ? sys-devel/gettext)
media-libs/imlib2-1.4.6-r2 (nls ? sys-devel/gettext)
media-libs/libexif-0.6.21-r1 (nls ? sys-devel/gettext)
media-libs/mesa-10.3.7-r1 (sys-devel/gettext)
media-sound/pulseaudio-5.0-r7 (>=sys-devel/gettext-0.18.1)
media-video/vlc-2.1.5-r1 (>=sys-devel/gettext-0.18.3)
net-analyzer/nmap-6.47-r1 (nls ? sys-devel/gettext)
net-dns/libidn-1.29 (nls ? >=sys-devel/gettext-0.17)
net-libs/glib-networking-2.42.1 (sys-devel/gettext)
net-libs/gnome-online-accounts-3.14.3 (sys-devel/gettext)
net-libs/gnutls-3.3.15 (nls ? sys-devel/gettext)
net-libs/libsoup-2.48.1 (sys-devel/gettext)
net-libs/libsoup-gnome-2.48.1 (sys-devel/gettext)
net-libs/webkit-gtk-2.4.8 (sys-devel/gettext)
net-libs/webkit-gtk-2.4.8-r200 (sys-devel/gettext)
net-misc/wget-1.16 (nls ? sys-devel/gettext)
sci-calculators/galculator-2.1.3 (sys-devel/gettext)
sys-apps/acl-2.2.52-r1 (nls ? sys-devel/gettext)
sys-apps/attr-2.4.47-r1 (nls ? sys-devel/gettext)
sys-apps/diffutils-3.3 (nls ? sys-devel/gettext)
sys-apps/findutils-4.4.2-r1 (nls ? sys-devel/gettext)
sys-apps/gawk-4.0.2 (nls ? sys-devel/gettext)
sys-apps/grep-2.21-r1 (nls ? sys-devel/gettext)
sys-apps/man-1.6g (nls ? sys-devel/gettext)
sys-apps/sed-4.2.1-r1 (nls ? sys-devel/gettext)
sys-apps/shadow-4.1.5.1-r1 (nls ? sys-devel/gettext)
sys-apps/texinfo-4.13-r2 (nls ? sys-devel/gettext)
sys-apps/util-linux-2.25.2-r2 (nls ? sys-devel/gettext)
sys-block/parted-3.2 (nls ? >=sys-devel/gettext-0.12.1-r2)
sys-boot/grub-2.02_beta2-r3 (nls ? sys-devel/gettext)
sys-devel/binutils-2.24-r3 (nls ? sys-devel/gettext)
sys-devel/bison-2.4.3 (nls ? sys-devel/gettext)
sys-devel/flex-2.5.39-r1 (nls ? sys-devel/gettext)
sys-devel/gcc-4.8.4 (nls ? sys-devel/gettext)
sys-devel/gdb-7.7.1 (nls ? sys-devel/gettext)
sys-devel/make-4.1-r1 (nls ? sys-devel/gettext)
sys-fs/e2fsprogs-1.42.12 (nls ? sys-devel/gettext)
sys-libs/e2fsprogs-libs-1.42.12 (nls ? sys-devel/gettext)
sys-libs/pam-1.1.8-r2 (nls ? sys-devel/gettext)
sys-process/psmisc-22.21-r2 (nls ? sys-devel/gettext)
virtual/libintl-0-r1 (!elibc_musl ?
>=sys-devel/gettext-0.18.3.2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
www-client/lynx-2.8.8_p2 (nls ? sys-devel/gettext)
x11-libs/gdk-pixbuf-2.30.8 (>=sys-devel/gettext-0.17)
x11-libs/gtk+-1.2.10-r12 (nls ? sys-devel/gettext)
x11-libs/gtk+-2.24.27 (sys-devel/gettext)
x11-libs/gtk+-3.14.9 (sys-devel/gettext)
x11-libs/gtksourceview-2.10.5-r2 (>=sys-devel/gettext-0.17)
x11-libs/gtksourceview-3.14.3 (>=sys-devel/gettext-0.17)
x11-libs/libXpm-3.5.11 (sys-devel/gettext)
x11-libs/libwnck-2.31.0 (sys-devel/gettext)
x11-libs/libxklavier-5.3 (sys-devel/gettext)
x11-libs/vte-0.28.2-r206 (sys-devel/gettext)
x11-misc/colord-1.2.9 (>=sys-devel/gettext-0.17)
x11-misc/notification-daemon-3.14.1 (sys-devel/gettext)
x11-misc/shared-mime-info-1.4 (sys-devel/gettext)
x11-misc/xscreensaver-5.32 (sys-devel/gettext)
x11-terms/xfce4-terminal-0.6.3 (sys-devel/gettext)
x11-themes/adwaita-icon-theme-3.14.1 (sys-devel/gettext)
x11-themes/gnome-icon-theme-3.12.0 (sys-devel/gettext)
x11-themes/sound-theme-freedesktop-0.8 (sys-devel/gettext)
xfce-base/exo-0.10.2-r1 (sys-devel/gettext)
xfce-base/garcon-0.2.1 (sys-devel/gettext)
xfce-base/libxfce4ui-4.10.0 (sys-devel/gettext)
xfce-base/libxfce4util-4.10.1 (sys-devel/gettext)
xfce-base/thunar-1.6.3 (sys-devel/gettext)
xfce-base/xfce4-appfinder-4.10.1 (sys-devel/gettext)
xfce-base/xfce4-panel-4.10.1 (sys-devel/gettext)
xfce-base/xfce4-session-4.10.1-r2 (sys-devel/gettext)
xfce-base/xfce4-settings-4.10.1 (sys-devel/gettext)
xfce-base/xfconf-4.10.0 (sys-devel/gettext)
xfce-base/xfdesktop-4.10.2 (sys-devel/gettext)
xfce-base/xfwm4-4.10.1 (sys-devel/gettext)
xfce-extra/xfce4-datetime-plugin-0.6.2 (sys-devel/gettext)
xfce-extra/xfce4-netspeed-plugin-0.3 (sys-devel/gettext)
xfce-extra/xfce4-xkb-plugin-0.5.6 (sys-devel/gettext)

> In my case, firefox does *not* show up, despite me using nls
> (neither does adobe-flash, in case you're using that).

In my case, the Firefox is already slow enogh especially on
starting, but that is probably because I use too many tabs.
(That did not slowed FF earlier until some update.)

> (I also thought that maybe firefox bundles gettext, but the
> only references I could find on developer.mozilla.org pertain
> to localising websites with php and the like, and not to
> firefox-internal technologies.)
>
> So it seems to me that gettext is a false lead and that the root
> of your problem lies somewhere else.

May be, but as I have already written it, I cannot think of a better
explanation why started in a default profile Firefox uses non-English
menu, but started in a new profile, it uses the English menu for the
same youtube video on the same web-page.

> This document shows how websites can localise their content:
> https://developer.mozilla.org/en-US/docs/Web_Localizability/Creating_localizable_web_applications.

Thank you for the link. I will look at it in more detail later, but from
the first look, the recommended localization method is using gettext.

> Marc Joliet
> --
> "People who think they know everything really annoy those of us who know we
> don't" - Bjarne Stroustrup

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 13:02 GMT+03:00  <rhannek@gmx.de>:
> On 30/05/15 11:36, gevisz wrote:
>>
>> P.S. As I have already described it earlier, this issue with the Firefox
>>      menu is only related to the menu I get while right-clicking on
>>      a youtube video in Firefox.  (All the other menus is in English,
>>      as desired.)
>>
>
> Have you checked the language settings at the bottom of the site?

I do not know how to do that.

> The menu you get is from the site and not from firefox.

Yes, but according to the link, provided by Marc, it contains
gettext instruction for its translation according to the locale
set on the local computer.

I get this issue for all youtube videos, either on youtube or
embedded into the html code on other web-sites: right-clicking
the video brings the menu in a non-English language. (One of its
entries in English is "Get embedded code".)

Moreover, if the menu "is from the site and not from firefox",
why I get it in English from the other instance of the Firefox
run in the same environment?

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 13:57 GMT+03:00 gevisz <gevisz@gmail.com>:

>> I strongly suspect that the application doing the translating doesn't
>> even use gettext.
>
> May be, but I cannot think of a better explanation.
>
>> Besides which, I'm surprised you're not getting crashes from
>> applications not finding the gettext libraries, which points
>> to them not actually using it.
>
> Nothing crashed so far and this, in my view, proves that should not
> be an obligatory dependency for any package in my wold file.

Correction:

Nothing crashed so far and this, in my view, proves that should not
be an obligatory dependency *on gettext* for any package in my wold file.

Re: [gentoo-user] Unwelcomed non-native language support

[rhannek]

On 30/05/15 14:07, gevisz wrote:
>I do not know how to do that.

Go to [1], scroll to the bottom. There should be some settings for yt
language.

>Yes, but according to the link, provided by Marc, it contains gettext
>instruction for its translation according to the locale set on the
>local computer.
>
>I get this issue for all youtube videos, either on youtube or embedded
>into the html code on other web-sites: right-clicking the video brings
>the menu in a non-English language. (One of its entries in English is
>"Get embedded code".)

No. It's about localizing web pages with gettext. gettext is on the
server side. The server sets a locale for the session and then localizes
your page accordingly via calls to gettext before you even get the page.

Basically on your first visit yt tries to guess your locale based on
several parameters. Mainly the Accept-Language http header (the thing in
Settings->Content which you already found). It stores whatever your
current setting is in your cookies and whenever you visit yt or have a
video embedded in some site this cookie determines the language for yt
content.

>Moreover, if the menu "is from the site and not from firefox", why I
>get it in English from the other instance of the Firefox run in the
>same environment?

It probably uses the same cookies.

[1] http://youtube.com

Re: [gentoo-user] Unwelcomed non-native language support

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

Am Sat, 30 May 2015 13:57:34 +0300
schrieb gevisz <gevisz@gmail.com>:

> > This document shows how websites can localise their content:
> > https://developer.mozilla.org/en-US/docs/Web_Localizability/Creating_localizable_web_applications.  
> 
> Thank you for the link. I will look at it in more detail later, but from
> the first look, the recommended localization method is using gettext.

Yes, but they are referring to *server side* use of gettext, e.g., when
generating a website using a template system, as is often done with Python or
PHP or ...

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 14:31 GMT+03:00  <rhannek@gmx.de>:
> On 30/05/15 14:07, gevisz wrote:
>>
>> I do not know how to do that.
>
> Go to [1], scroll to the bottom. There should be some settings for yt
> language.
>
>> Yes, but according to the link, provided by Marc, it contains gettext
>> instruction for its translation according to the locale set on the
>> local computer.
>>
>> I get this issue for all youtube videos, either on youtube or embedded
>> into the html code on other web-sites: right-clicking the video brings
>> the menu in a non-English language. (One of its entries in English is
>> "Get embedded code".)
>
>
> No. It's about localizing web pages with gettext. gettext is on the
> server side. The server sets a locale for the session and then localizes
> your page accordingly via calls to gettext before you even get the page.
>
> Basically on your first visit yt tries to guess your locale based on
> several parameters. Mainly the Accept-Language http header (the thing in
> Settings->Content which you already found). It stores whatever your
> current setting is in your cookies and whenever you visit yt or have a
> video embedded in some site this cookie determines the language for yt
> content.

Ok, thank you for explanation. If the localization is done on the server
side, then cleaning the cookies should help and it indeed helped: the
menu returned to its English view as soon as I deleted all my cookies
from youtube.

>> Moreover, if the menu "is from the site and not from firefox", why I
>> get it in English from the other instance of the Firefox run in the
>> same environment?
>
> It probably uses the same cookies.

Probably you meant "the different cookies."

> [1] http://youtube.com

Too late get your explanation about checking the "yt language."
Now, after deleting all youtube cookies, it is set to English as desired.

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 14:36 GMT+03:00 Marc Joliet <marcec@gmx.de>:
> Am Sat, 30 May 2015 13:57:34 +0300
> schrieb gevisz <gevisz@gmail.com>:
>
>> > This document shows how websites can localise their content:
>> > https://developer.mozilla.org/en-US/docs/Web_Localizability/Creating_localizable_web_applications.
>>
>> Thank you for the link. I will look at it in more detail later, but from
>> the first look, the recommended localization method is using gettext.
>
> Yes, but they are referring to *server side* use of gettext, e.g., when
> generating a website using a template system, as is often done with
> Python or PHP or ...

Ok, thank you for explanation about the server side localization.
Now, after deleting all youtube cookies the issue is solved. :-)

So, I can update the system and see if the unneeded gettext package
will be emerged again. :-)

Re: [gentoo-user] Unwelcomed non-native language support

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

Am Sat, 30 May 2015 14:59:12 +0300
schrieb gevisz <gevisz@gmail.com>:

> 2015-05-30 14:31 GMT+03:00  <rhannek@gmx.de>:
> > On 30/05/15 14:07, gevisz wrote:
[...]
> > No. It's about localizing web pages with gettext. gettext is on the
> > server side. The server sets a locale for the session and then localizes
> > your page accordingly via calls to gettext before you even get the page.
> >
> > Basically on your first visit yt tries to guess your locale based on
> > several parameters. Mainly the Accept-Language http header (the thing in
> > Settings->Content which you already found). It stores whatever your
> > current setting is in your cookies and whenever you visit yt or have a
> > video embedded in some site this cookie determines the language for yt
> > content.
> 
> Ok, thank you for explanation. If the localization is done on the server
> side, then cleaning the cookies should help and it indeed helped: the
> menu returned to its English view as soon as I deleted all my cookies
> from youtube.
> 
> >> Moreover, if the menu "is from the site and not from firefox", why I
> >> get it in English from the other instance of the Firefox run in the
> >> same environment?
> >
> > It probably uses the same cookies.
> 
> Probably you meant "the different cookies."
> 
> > [1] http://youtube.com
> 
> Too late get your explanation about checking the "yt language."
> Now, after deleting all youtube cookies, it is set to English as desired.

Great that you got it to work :) .

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 15:02 GMT+03:00 gevisz <gevisz@gmail.com>:
>
> So, I can update the system and see if the unneeded
> gettext package will be emerged again. :-)

Yes, it was merged back. Why

... to keep an unneeded dependency in the portage tree?

Re: [gentoo-user] Unwelcomed non-native language support

[Peter Humphrey]

On Saturday 30 May 2015 13:57:34 gevisz wrote:
> 2015-05-30 12:32 GMT+03:00 Marc Joliet <marcec@gmx.de>:
> > Am Sat, 30 May 2015 11:36:28 +0300
> > schrieb gevisz <gevisz@gmail.com>:
> > [...]
> > (Note: the word you are looking for is "cache".)
> 
> So, it is from French.

[OT]
Yes, along with a vast number of other common words in English; they came 
along with the Normans in 1066 and afterwards. Far more than from German or 
Dutch, and those are far more than from Spanish or Italian.
[/OT]

> When I learned it in high school, this word was not in our vocabulary. :-)
> 
> > I strongly suspect that the application doing the translating doesn't
> > even use gettext.
> 
> May be, but I cannot think of a better explanation.
> 
> > Besides which, I'm surprised you're not getting crashes from
> > applications not finding the gettext libraries, which points
> > to them not actually using it.
> 
> Nothing crashed so far and this, in my view, proves that should not
> be an obligatory dependency for any package in my wold file.
> 
> >  You can use "emerge --depclean -pv gettext" to determine which do.
> 
> $ emerge --depclean -pv gettext
> --- Couldn't find 'gettext' to depclean.
> 
> >>> No packages selected for removal by depclean
> 
> However, running
> # equery depends gettext
> before forcefully unmerging the gettext package,
> I got the following response:
>  * These packages depend on gettext:

-->8

I have gettext installed, and pretending to depclean it showed 77 packages 
depending on it. I see it's similar for you.

> > So it seems to me that gettext is a false lead and that the root
> > of your problem lies somewhere else.
> 
> May be, but as I have already written it, I cannot think of a better
> explanation why started in a default profile Firefox uses non-English
> menu, but started in a new profile, it uses the English menu for the
> same youtube video on the same web-page.

Have you tried a revdep-rebuild recently? It seems to me that you need gettext 
put back in, and maybe other things too.

-- 
Rgds
Peter

Re: [gentoo-user] Unwelcomed non-native language support

[rhannek]

On 30/05/15 16:56, gevisz wrote:
>2015-05-30 15:02 GMT+03:00 gevisz <gevisz@gmail.com>:
>>
>> So, I can update the system and see if the unneeded
>> gettext package will be emerged again. :-)
>
>Yes, it was merged back. Why
>
>... to keep an unneeded dependency in the portage tree?
>

Because some package needs gettext. You might check if upstream or the
ebuild can be patched to make the dependency optional or search for
alternatives.

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 18:54 GMT+03:00 Peter Humphrey <peter@prh.myzen.co.uk>:
> On Saturday 30 May 2015 13:57:34 gevisz wrote:
>> 2015-05-30 12:32 GMT+03:00 Marc Joliet <marcec@gmx.de>:
>> > Am Sat, 30 May 2015 11:36:28 +0300
>> > schrieb gevisz <gevisz@gmail.com>:
>> > [...]
>> > (Note: the word you are looking for is "cache".)
>>
>> So, it is from French.
>
> [OT]
> Yes, along with a vast number of other common words in English; they came
> along with the Normans in 1066 and afterwards. Far more than from German or
> Dutch, and those are far more than from Spanish or Italian.
> [/OT]
>
>> When I learned it in high school, this word was not in our vocabulary. :-)
>>
>> > I strongly suspect that the application doing the translating doesn't
>> > even use gettext.
>>
>> May be, but I cannot think of a better explanation.
>>
>> > Besides which, I'm surprised you're not getting crashes from
>> > applications not finding the gettext libraries, which points
>> > to them not actually using it.
>>
>> Nothing crashed so far and this, in my view, proves that should not
>> be an obligatory dependency for any package in my wold file.
>>
>> >  You can use "emerge --depclean -pv gettext" to determine which do.
>>
>> $ emerge --depclean -pv gettext
>> --- Couldn't find 'gettext' to depclean.
>>
>> >>> No packages selected for removal by depclean
>>
>> However, running
>> # equery depends gettext
>> before forcefully unmerging the gettext package,
>> I got the following response:
>>  * These packages depend on gettext:
>
> -->8
>
> I have gettext installed, and pretending to depclean it showed 77 packages
> depending on it. I see it's similar for you.
>
>> > So it seems to me that gettext is a false lead and that the root
>> > of your problem lies somewhere else.
>>
>> May be, but as I have already written it, I cannot think of a better
>> explanation why started in a default profile Firefox uses non-English
>> menu, but started in a new profile, it uses the English menu for the
>> same youtube video on the same web-page.
>
> Have you tried a revdep-rebuild recently? It seems to me that you
> need gettext put back in, and maybe other things too.

Yes, it was merged back on the today's system update.

I have already complained about it.

Re: [gentoo-user] Unwelcomed non-native language support

[gevisz]

2015-05-30 18:56 GMT+03:00  <rhannek@gmx.de>:
> On 30/05/15 16:56, gevisz wrote:
>>
>> 2015-05-30 15:02 GMT+03:00 gevisz <gevisz@gmail.com>:
>>>
>>>
>>> So, I can update the system and see if the unneeded
>>> gettext package will be emerged again. :-)
>>
>>
>> Yes, it was merged back. Why
>>
>> ... to keep an unneeded dependency in the portage tree?
>>
> Because some package needs gettext.

None of my two-fullscreen dependency packages really need it.

> You might check if upstream or the ebuild can be patched
> to make the dependency optional or search for alternatives.

Good advice. :)

I have to read the dev's manual first, I guess.

Anyway, I was intended to do it someday, when I'll have some
free time during the winter...

Re: [gentoo-user] Unwelcomed non-native language support

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

On Sat, 30 May 2015 13:57:34 +0300, gevisz wrote:


> Nothing crashed so far and this, in my view, proves that should not
> be an obligatory dependency for any package in my wold file.

That only shows that you have not used any function that requires
gettext, not that none use it.

> >  You can use "emerge --depclean -pv gettext" to determine which do.
> 
> $ emerge --depclean -pv gettext
> --- Couldn't find 'gettext' to depclean.
> >>> No packages selected for removal by depclean

It needs to be installed, now that your update has pulled it back in try
depclean again.

> However, running
> # equery depends gettext
> before forcefully unmerging the gettext package,
> I got the following response:

equery depends always used to be unreliable when it came to USE
controlled dependencies. emerge --depclean gives the authoritative answer
and it considers the portage tree, USE flags and dependencies at the
time it is run.

> app-editors/gvim-7.4.273 (nls ? sys-devel/gettext)
>                              %%% Even gvim! And it definitely does not
> crash without gettext

% grep gettext /var/portage/app-editors/gvim/gvim-7.4.712.ebuild 
        nls? ( sys-devel/gettext )

Yes, equery is still getting it wrong, gvim only depends on gettext when
built with USE=nls.

> > So it seems to me that gettext is a false lead and that the root
> > of your problem lies somewhere else.
> 
> May be, but as I have already written it, I cannot think of a better
> explanation why started in a default profile Firefox uses non-English
> menu, but started in a new profile, it uses the English menu for the
> same youtube video on the same web-page.

Because there is a language setting in your current profile. If this were
a system default, the new profile would exhibit the same behaviour. If
Firefox is the only program that is misbehaving, and then only with an
existing profile, I would not look further afield for blame.


-- 
Neil Bothwick

Puns are bad, but poetry is verse...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

Am Sun, 31 May 2015 09:48:08 +0100
schrieb Neil Bothwick <neil@digimed.co.uk>:

> > app-editors/gvim-7.4.273 (nls ? sys-devel/gettext)
> >                              %%% Even gvim! And it definitely does not
> > crash without gettext  
> 
> % grep gettext /var/portage/app-editors/gvim/gvim-7.4.712.ebuild 
>         nls? ( sys-devel/gettext )
> 
> Yes, equery is still getting it wrong, gvim only depends on gettext when
> built with USE=nls.

I don't get this.  equery is showing *exactly* the same information as your
grep.  It's not wrong, it's just that it only shows that gvim *might* depend on
gettext, namely when the nls USE flag is set, while "emerge --depclean -pv"
will give you a definitive yes/no answer (although automagic dependencies might
still render its answer incorrect).  However, emerge won't tell you *why*, so
strictly speaking you need both for a full answer.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Unwelcomed non-native language support

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Sun, 31 May 2015 12:59:32 +0200, Marc Joliet wrote:

> > 
> > Yes, equery is still getting it wrong, gvim only depends on gettext
> > when built with USE=nls.  
> 
> I don't get this.  equery is showing *exactly* the same information as
> your grep.  It's not wrong, it's just that it only shows that gvim
> *might* depend on gettext, namely when the nls USE flag is set,

Yes the OP listed a long list of packages that he thought did depend on
gettext, even though they do not with hi current settings.

> while
> "emerge --depclean -pv" will give you a definitive yes/no answer
> (although automagic dependencies might still render its answer
> incorrect).  However, emerge won't tell you *why*, so strictly speaking
> you need both for a full answer.

depclean tells you which package depends on the package you want to
remove, examination of the ebuild is usually the most reliable way of
determining whether that need is USE controlled.

The main disadvantage of depclean IMO is that it shows ony one package
that depends on the package you want to remove, not all the relevant parts
of the dependency chain. If the package you want to reove is not
system-critical, the easiest option is often to quickpkg it, remove it
and then look at the output from

emerge --tree --update --deep @world


-- 
Neil Bothwick

Intel: where Quality is job number 0.9998782345!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]