In bug #97401 it was claimed that Adobe acrobat cannot be installed with multiple languages in the same system. This is not true. As I cannot reopen that bug I'm creating a new one. For example, I have LINGUAS="en fi" (English, Finnish) in my make.conf. Currenct acrobat ebuild installs only finnish, ie. installs the binary package http://ardownload.adobe.com/pub/adobe/reader/unix/7x/7.0.5/suo/AdobeReader_suo-7.0.5-1.i386.rpm to my system and that's it. You CAN install multiple languages. The trick is simple - now that the Finnish version is done, I can put in the English language by simply downloading the english tarball (or rpm) from Adobes site (adobereader_enu-7.0.5). Then, instead of exctracting all the files, I only take out stuff under Acrobat7/Resource/Linguistics/ For Finnish, the stuff that goes in is --- /opt/Acrobat7/Resource/Linguistics/LanguageNames/ >>> /opt/Acrobat7/Resource/Linguistics/LanguageNames/DisplayLanguageNames.fi_FI.txt --- /opt/Acrobat7/Resource/Linguistics/Providers/ --- /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/ >>> /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/fin32.clx >>> /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/fin49.lex >>> /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/finphon.env The english version has ONLY different stuff there. (This output is from my upgrade from 7.0.5-r1 to 7.0.5-r2 where the ebuild suddenly decidced to go finnish). <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/usa8604.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/usa8603.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/usa8602.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/usa8601.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/usa86.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/engphon.env <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/eng32.clx <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/canphon.env <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/can32.clx <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/can112.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/brtphon.env <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/brt32.clx <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/brt0402.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/brt0401.lex <<< obj /opt/Acrobat7/Resource/Linguistics/Providers/Proximity/brt04.lex <<< obj /opt/Acrobat7/Resource/Linguistics/LanguageNames/DisplayLanguageNames.en_US.txt So, it should be possible to modify the ebuild so that it would 1. Download the file indicated by the FIRST linguas bit, install acroread normally 2. Download the files indicated by OTHER linguas bits, and only extract the stuff under Resource/Linguistics. 3. Exctract the file bin/acroread from packages OTHER linguas bits. The last step causes most difficulties. Right now I have made as such: bin/acroread from finnish package is placed at /opt/Acrobat7/acroread_fi bin/acroread from english package is placed at /opt/Acrobat7/acroread_en A wrapper script at /opt/Acrobat7/acroread that basically acts as follows if LANG=fi && acroread_fi if LANG=en && acroread_en acroread_en // As fallback I'm suggesting that this should be expanded, either by modifying the acroread script (ie. merging all the scripts from various languages into one) or building a more robust wrapper that chooses the language based on users locale information (LANG or LC_MESSAGES).
Reassigning to the right herd for consideration
(In reply to comment #1) > Reassigning to the right herd for consideration > My LINGUAS: LINGUAS="en_US en ar ca cs da de el en_GB es fi fr ga he hu it ja ko mk nb nl nn pl pt_BR ro ru sk sl sv tr zh_CN zh_TW es_AR es_ES ga_IE nb_NO sv_SE" When I install acroread, it defaults to German. Why?
(In reply to comment #2) > When I install acroread, it defaults to German. Why? Because the acroread ebuild logic is daft. It installs the first langauge in the ordered list "de fr sv es pt no it fi nl da ja ko zh_CN" that is also in LINGUAS - unless nothing matches in which case it installs English. No prizes for guessing the native language of the dev who added that logic to the ebuild... While it installs just one language, it should install the first one from LINGUAS that is available (not the first one in its alphabetically-ordered list of available languages). Alastair - why is this assigned to cjk@ and not printing@? I don't see anything CJK-specific here, and the maintainer is listed as printing@.
Can you please apply a working patch for me? I will be glad to fix this thing.
Created attachment 102478 [details] Multi-lingual ebuild Here's a version that installs all matching available languages, with a little wrapper if necessary. Comments and review, please :) I haven't figured out how to get the language drop-down to contain other languages; so what this does is choose the language via a simple wrapper using LANG. Most files are common; each additional language consumes about 10MB of disk space. The ebuild crafts a simple wrapper to select which launch script (which is language-specific; contains the localised license terms etc) to use at runtime according to LANG. Note that the main executable itself is not language specific. Once the application is launched once by a user, that user will always see the same language (even if LANG is changed) unless the preferences are changed to "Choose at application startup" (Edit->Preferences->International), after which if LANG is set the next time it is started, it'll let you choose between the language in LANG and English. Note that LANG should be a valid locale; e.g. 'de_DE' not just 'de', as always. Be aware that if you have all possible languages in LINGUAS, the download is some 650MB; each individual download package is somewhat over 40MB or so. I've tested this with FIGS (French, Italian, German, Spanish in addition to English). It needs to be tested also with the other languages; in particular the non-European langauges. I have another version of the ebuild that doesn't use LINGUAS, and installs the language selected by specifying USE=acrolingua_<lang>, but it's not particularly nice.
cool. Nice ebuild! Though I have only LC_ALL=de_DE.UTF-8 set here and I suppose it would not work then. Maybe better offer the first ebuild lingua !english to get the selection on first startup? Also I would like to see english only as default instead of every language. 690 MB is a lot of download. I think neither we nor adobe nor our users want that.
The ebuild uses LINGUAS to decide what languages to install. If you have empty LINGUAS you get just English. If you set LINGUAS to one entry, you'll get the one you asked for (assuming it's supported). If you set it to more than one, you'll get all of those languages that are supported. I've updated the wrapper to use LC_ALL or LC_MESSAGES in addition to LANG, with the precedence LC_ALL, LC_MESSAGES, LANG (as with the C library) - as Antti suggested. As discussed in IRC, I've committed it but masked it at the same time. Testing would be appreciated (especially from people who know what the various Asian fonts should look like - I can tell that they're different from each other, but not whether they're correct!) - add "=app-text/acroread-7.0.8-r1" to /etc/portage/package.unmask to get it.
I guess you implemented this now - at least my acroread 7.0.9 seems to work now as suggested.
Oh yeah :) Thanks for the note. BTW you may prefer 7.0.9-r1 - there's a fix to the wrapper to pass parameters to acroread (so it works when invoked from file managers etc).
(In reply to comment #9) > Oh yeah :) Thanks for the note. > > BTW you may prefer 7.0.9-r1 - there's a fix to the wrapper to pass parameters > to acroread (so it works when invoked from file managers etc). Silly question but why isn't 7.0.9-r1 stable? I'd say that due to the parameter handling bug 7.0.9 is actually broken since parameters don't get passed (so you cannot say 'acroread xxxx.pdf' anymore)?
Since it's not a security bug, there's no over-riding rush to stable. Normal procedure is to have things unstable (~) for a while (typically a month) to flush out any other obvious bugs or problems there may be. The only reason 7.0.9 got marked stable quickly (in terms of ebuild in the tree -> stable marking) was to deal with the security issue - if it wasn't for that, it'd be unstable (and I wouldn't have had to create 7.0.9-r1). I also want to consider doing the wrapper differently, so that changes in language work more simply (currently they only occur if you set Acroread to ask for the language at startup).
