The code in the acroread 7 ebuild file that tries to find out which language the user wants to install is not too clever. It runs along a list and breaks when it finds a match in the linguas in the make.conf What if your default language is not first in the list or in the list at all. For example, my default is English but my linguas list Japanese, Chinese and Korean in that order. So I ended up with Japanese acroread. There should be a clearer way of specifying the desired language. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Stefan, could you look at Bug 92699, comment #16 if it's a viable solution?
does the japanese acroread not include the english text and you can switch on startup? For the german version this is possible.
My LINGUAS is: LINGUAS="en_GB fr" and I only get the French version. And no I can't switch to English.
I ran into this too. acroread-asianfonts told me to add "ja" to my LINGUAS to get the Japanese fonts (so I changed it to LINGUAS="en ja"), which then causes acroread to install the Japanese version. As I'm just a student of Japanese, I can't tell if there's any way to turn on English test---the GUI is all in Japanese. I suspect this is a not-uncommon situation, so even if there is a way to switch to english, the current scheme isn't acceptable. BTW, portage also gets confused by acroread-7 being stable but acroread-asianfonts-7 being unstable. It keeps threatening to downgrade to acroread-5 (though it never seems to actually do it).
To add a note of confirmation; I just installed and it came up in German, only. The choice to select languages only offers German. My LINGUAS is set to: LINGUAS="en_GB it de es fr" 'de' being the first SRC_URI that matched. THe problem doesn't go away by adding a 'linguas_en?...' line at the start - people who have, for example, "fr en" would end up with English when they obviously want French if only one can be installed. The natural interpretation of LINGUAS is that support for all languages specified should be included if possible (in which case, 'strip-linguas' from the eutils eclass is probably a good idea). However, if that's not possible then the natural expectation is that the first supported language from LINGUAS will be installed. I'm not sure that's trivial however, whilst obeying the rules about variables like SRC_URI; but there may some ideas worth stealing from the kde-meta ebuild & kde-functions.eclass.
In view of GLSA 200507-09 (Adobe Acrobat Reader: Buffer overflow vulnerability), this has moved from minor annoyance to major problem. According to that advisory, I need to upgrade to Acrobat 7, but with the current emerge, the only way I can do that is (and not get a Japanese version) is to unset LINGUAS entirely, which will mess up other ebuilds. So could we get a fix for this (even if not a perfect one) quickly?
Mark, the easiest way to get it installed in English is to do: LINGUAS="en" emerge acroread which will get you up to v7 with the US English version (change 'en' to the language you want, chosen from the supported list; de, fr, ja, ko, zh_CN, zh_TW). You don't need to change the LINGUAS variable in make.conf, the one specified on the command line above overrides. That way any other emerges you do later won't be affected. If 'emerge -pv acroread' shows it will update other packages first, emerge them first as normal before doing the above trick just for acroread.
I've had a play around and I think there's no way to get things working satisfactorily with SRC_URI and LINGUAS as they stand today, ensuring that (1) digests are built properly (2) users only download the selected language file and (3) the user gets the language they expect. Unless someone comes up with a cunning trick to satisfy 1, 2, and 3, I'd suggest the easiest way to make the ebuild sane is to define local use flags for each language acroread supports and avoid LINGUAS completely (i.e. replace 'linguas_' with 'acroread_', add to IUSE, and to use.desc.local - where a comment that only one acroread_<lang> should be specified by the user would be sensible).
For the acroread ebuild maintainer(s), A simple correction for systems with English upfront in the LINGUAS variable (with other languages present), is done just by changing the beginning of the SRC_URI to: SRC_URI="linguas_en? ( ${SRC_HEAD}/enu/AdobeReader_enu${SRC_FOOT} ) !linguas_en? ( linguas_de? ( ${SRC_HEAD}/deu/AdobeReader_deu${SRC_FOOT} ) [...]" Unfortunatly this does not resolve the order problem, it selects the first in the ebuild order that is present in the entire LINGUAS string; if you have LINGUAS="fr de", for example, the German version is selected. There are also other ebuilds, such as nwn, that don't have the conditional "en". Just wondering if the Gentoo Developer Docs have a passage concerning the i18n aspects of ebuild programming. Is there a linguas "get" command given the index, i.e., for iteration use?
This seems to be unfixed, is it assigned to the correct team?
This cannot be fixed due to Acrobat not allowing multiple languages on the same system. Portage cannot detect only the first language in linguas, so we have to take one of them based on a random list, sorry.
As noted in Bug 92699, comment #16 (referenced in comment #1 above), openoffice manages to detect only the first language in linguas with no problem. So CANTFIX is not correct. If no one wants to fix this, mark it WONTFIX.
ok, here for you again: Adobe does not provide one big package and small language extensions Openoffice does. We cannot go the way of uselessly downloading and installing everything as openoffice-bin does because adobe provides only big packages and does not give a way to install multiple languages. Because portage cannot detect the first language-code in linguas we cannot fix this. And please talk to me in IRC if you still have problems with understanding why it does not work instead of spamming this bug. Oh, and sure I want to fix it. I would have already done it, if I had a solution.
*** Bug 107937 has been marked as a duplicate of this bug. ***