there's a problem with all 1.1.x ebuilds. I do: LANGUAGE="49" emerge openoffice and I have a fully german (49=de) OpenOffice. All, but the online-help! The help-dialog is in german, but the help texts are in english. That's odd! If I download the german binary package fom openoffice.org, then the help texts are also in german. Reproducible: Always Steps to Reproduce: LANGUAGE="49" emerge openoffice Actual Results: application in german, online help in english Expected Results: everything in german
Created attachment 34162 [details] ooo-help.png as you can see: application in german, help texts in english
This is a very old issue (see bug #33007). Since the maintainers of the openoffice ebuild don't seem to have time to implement this, I tried to solve it. I attached a diff against the current openoffice 1.1.2 ebuild and the patched ebuild for convenience. This patch was mostly inspired by an ebuild kurt posted in this thread of the gentoo-forum (in german) for an other openoffice version: http://forums.gentoo.org/viewtopic.php?t=134865 Fetching the right language pack didn't work with it so i changed it a lot. I'm not sure how this should be done, I just did it similar as i saw it in the koffice-i18n ebuild. There is one shortcome the way I did it: if you change the value of LANGUAGE, the ebuild will still fetch the previous file. I think this does not happen very often and as a simple workaround for this, you just need to touch the ebuild. I only tested it with LANGUAGE="49" (german), but it should work with all the other languages as well (I implemented all I could find). If there is no language pack for the selected language, the default english helpcontent is used. You will also need a new digest with the md5sums of the language packs, I attached it as well. Maybe one of the maintainers of this ebuild can check what I did and then hopefully add it to portage soon :-).
Created attachment 34278 [details, diff] Patch against openoffice 1.1.2 ebuild
Created attachment 34279 [details] Patched ebuild
Created attachment 34280 [details] New digest with language packs
hey, thanks! I'll test it later. Feedback comes after testing (and compiling). So give me 1 or 2 days.
ok, emerge runs now... takes some time ;) But now I know the problem: helpcontent_49_unix.tgz isn't portage compatible, because of the missing version. This can be solved, by manually upload a versioned file. This has to be done by the maintainer. (s)he has to download helpcontent_XX_unix.tgz, rename it to helpcontent_XX_unix-1.1.2.tgz and upload it to the mirrors then. The other option is, to ask the openoffice-team to version their helpfiles. This could be done easily by providing a simple softlink on the ftp server, so old links aren't broken.
@maintainer(s): having localized helpfiles is absolutely IMPORTANT! Not everyone is able to understand english. My mom for example. ;-) And yes, she is using Gentoo-Linux as a pure user (I'm the family-admin).
This doesn't make much sense to me. The helpcontent is the same for all 1.1.x versions of openoffice. The only problem I see is that there are helpcontent files for version 1.0.x in another directory on that server with the same name. This can become a problem in the future, but for now it isn't. Technically they are compatible with portage. There are a lot of files without version in my distfiles directory, for example win32codecs.tar.bz2 or arial32.exe. But I agree that to prevent future problems, the openoffice team should include version numbers in the filename and not just put it into another directory. It is generally a bad idea to give different files the same name. This version can be something like helpcontent_XX_unix-1.1.tgz for openoffice 1.1.x, as it is done for k3b. @Stefan Is it working? It should have fetched the correct file and unpacked it. If you have seen some output of unzip (inflating this and that) after unpacking source, you should be fine. The actual compile process is not influenced by the changed helpcontent.
I open a BugZilla @ openoffice.org for this. and yes, files were fetched correct. But the emerge is still running. ;-)
OK, it works!!! please add this ASAP! thanks! ;-)
Hi, looks like a great job :) 01 | ENUS ) SRC_URI="$SRC_URI $BASEDIR/helpcontent_01_unix.tgz" ;; I guess you could leave that one out, as english version of help installs anyway if one of the other languages is not specified. Or am I wrong there and it should be put there? I don't want to open a new bug as yet, but is it possible that You guys envolve this ebuild even further. What I am missing in it is a multilanguage support for more than one language. It has to be possible to have more versions available for multiuser enviroments. At present ebuild assumes only one language to be available. eg. LANGUAGE="03". If it is set to more eg. LANGUAGE="01 03 48" than it treats it as wrongfully set: * Unknown LANGUAGE setting! * * Known LANGUAGE settings are: * ENUS | PORT | RUSS | GREEK | DTCH | FREN | SPAN | FINN | CAT | ITAL | * CZECH | SLOVAK | DAN | SWED | POL | GER | PORTBR | THAI | ESTONIAN | * JAPN | KOREAN | CHINSIM | CHINTRAD | TURK | HINDI | ARAB | HEBREW !!! ERROR: app-office/openoffice-ximian-1.1.60 failed. !!! Function set_languages, Line 174, Exitcode 0 !!! (no error message) Counting on YOU :)
there's the LINGUAS variable, which almost all KDE apps are using. We should use it also for other ebuilds, incl. openoffice, if possible.
I know that there is LINGUAS variable to be set. I have seen a bug report about it as well. Of course it would be great to chage in to this parameter from LANGUAGE. Simple change however (even so important) does not make it possible to install several languages (could be wrong there). Reason I said this change needs to be done in LANGUAGE is because it could mean less work (possibly). If possible to get both changed at the same time would be even greater (no doubt). :)
You are right, since 01/ENUS is default I skipped this one. Putting it in would increase the download for english speakers, so leaving it out would be best. Multiple language support is not possible with openoffice 1.x, afaik. I think this is the reason why they didn't implement LINGUAS support yet. It would be as simple as including a translation table in the ebuild, e.g. if LINGUAS="de" then set LANGUAGE="49". BUT you can use multiple languages in LINGUAS, and which one do we translate then? The first? I think this would quite confusing. Using a seperate variable (LANGUAGE) that is only used by openoffice is a much cleaner way to implement this. Openoffice 2.0 will probably have language pack support, you will be able to switch UI language (and probably help language, too) the way you can do it in mozilla.
well, is LANGUAGE is set, then use this. if only LINGUAS is set, then extract the first non-english language (if present) and use this one. An einfo message could tell the user which language is set, if there's more than one non-english language in LINGUAS + hint to set LANGUAGE if one wants a different language. the advantage of supporting LINGUAS is, that 80% of non-english users would be happy, since they normally have only one language in LINGUAS (their native language) and LANGUAGE is not only obsolete, it's confusing cause of a totally different syntax. furthermore: we would be prepared for OOo 2.x ;-)
Well, OOo 2.x won't need any LINGUAS support, because this will be done by the user (see mozilla, it's english by default and you just download and install a language pack from within the options dialog). So there is no need to be prepared... All we are talking about is OOo 1.x. Would it really be useful to implement this? Most users won't compile OOo, the will use the binary package, because compiling this takes a lot of time and there is almost no benefit in building it from source (most optimizations are turned off by default to make it compile). And the few users that don't like prebuilt binarys and compile it on their own already know that they have to use LANGUAGE instead of LINGUAS. If you still think LINGUAS should be used, I can try to implement it if I have some time (currently I haven't, the storm in bavaria took 4 trees in our garden and i have plenty of work to tidy up the mess). And remember, I'm neither a programmer nor a maintainer of this ebuild. And if I successfully implement this, there would be no guarantee it will be used. Unfortunately no maintainer showed up in this bug yet (hint, hint)...
> Well, OOo 2.x won't need any LINGUAS support, because this will be done by > the user (see mozilla, it's english by default and you just download and > install a language pack from within the options dialog). So there is no need > to be prepared... wuahh! ;-) even then we need LINGUAS, because you could download the language packs automatically and install them system-wide. We need this also for Mozilla. It's crap to download the language packs manually after each update. And then, it's only for that user. If you want to install it system-wide, then you have to be root and it will be installed somewhere into the system, passing by the package manager. STUPID^10! We have portage to do things automatically. We really don't want to do such things manually.
I didn't say it would not be nice to have LINGUAS support for OOo 2.x, I said it would not be needed ;-) And if someone implements this it would be completely different than in 1.x, so there is no way to be prepared. I don't know if it will be even possible (is it possible to do this automagically with mozilla? why isn't it implemented there?) But then, i think we get completely off-topic now ;-)
> I don't know if it will be even possible (is it possible to do this > automagically with mozilla? why isn't it implemented there?) don't know. same reason not to implement i18n-helpfiles for OOo, yet? this is a topic I will watch after this Bug is closed! ;-)
remind, remind ;-)
The linguas issue is a gentoo general issue. The problem is that there is no real support for language selection in gentoo. That is also the cause that the help packs are not provided in the localisation as doing so would cause all users to download all localised help files. Even the ones they are not interested in. Unfortunately the patch is invalid as the value of variables needs to be constant for caching and other things to work.
Now I'm a bit confused...what exactly is invalid? Changing the value of SRC_URI? It is done exactly the same way in the koffice-i18n or xfree ebuilds (and probably more). It works perfectly, so I see no point here. In the kde-i18n ebuild, they use use-flags (e.g. linguas_de) to select the desired language-pack(s). I couldn't find where the LINGUAS variable is translated to use flags (e.g. de -> linguas_de), so it's impossible for me to adapt this behaviour for the openoffice-ebuild. Simply using LINGUAS instead of LANGUAGE is no option since openoffice only supports one language at a time and LINGUAS can be more than one (I guess most users will only have one languge in their LINGUAS, but who knows). One would have to make sure that maybe only the first one is used (if it is supported by OOo).
Changing SRC_URI is indeed invalid. If kde-i18n and/or xfree do that those ebuilds are broken and might get very strange behaviour when the LINGUAS variable is actually defined. It also fails in creating correct digests. It is broken and only seems to work perfect. The useflag translation happens somewhere in portage, but I don't know exactly where.
I tried to filter all ebuilds that actually change SRC_URI. I Used the following command to list all ebuilds that define SRC_URI more than one time (outside a comment): grep -r -c -e "^\([^#].*\)*SRC_URI=" * |grep -v ":0" |grep -v ":1" Then I checked the result (by hand). I discovered 60 ebuilds that change SRC_URI, 12 that don't change it, but define it at least twice (usually depending on some conditions) and there was one invalid hit. You can see the full list at the end of this post. Changing SRC_URI seems to be a quite common "hack". So all those 60+12 ebuilds are broken? There are a lot of "core" components in this list (gcc, glibc, xfree, ...), which should really be fixed then... By the way, I didn't find anything in the ebuild-howto that forbids changing SRC_URI (it just says, I MUST set it...). Maybe you can point me to the right place? The ebuild will create a valid digest! I agree that those digests depend on the value of LANGUAGE, wich should be a minor problem since you only need the checksums for your selected language pack and the digests with all packs will be downloaded from portage anyway. (The same happens for kde-i18n and probably all ebuilds with "<use variable>? <src url>" expressions.) Caching should be no problem, since LANGUAGE will not be changed, actually it will be defined once (probably in make.conf) and never be touched again on most systems. If you dislike changing SRC_URI, it can of course just be defined several times (depending on which LANGUAGE is set). I can also imagine some different approaches to get the right language pack: - introducing a couple of use-flags, like ooohelp049 etc and using something like oohelp049? <scr of language pack>. This will make the openoffice install more complicated. - splitting the ebuild into openoffice(-en) openoffice-de etc, which would actually make LANGUAGE obsolete and probably be the cleanest solution (but would also make the ebuilds harder to maintain). - maybe it is possible to introduce separate ebuilds like openoffice-doc-de. I haven't yet looked at this in detail, but I think the docs only need to be extracted to the right place (/opt/Openoffice.org/help). - using LINGUAS instead of LANGUAGE. Then it would be possible to use linguas_de? <url> as it is done in kde-i18n. Unfortunately OOo only supports a single language and I am not sure what happens if LINGUAS contains more than one language (probably it will download multiple language packs, but use only one, maybe the first). Finally here is the list of ebuilds that change SRC_URI. All ebuilds that do not actually change SRC_URI but define SRC_URI at least twice are marked with "*". The invalid hit is marked with "-". app-cdr/k3b/k3b-0.11.12-r1.ebuild:2 app-cdr/k3b/k3b-0.11.13.ebuild:2 app-cdr/k3b/k3b-0.11.10.ebuild:2 app-i18n/koffice-i18n/koffice-i18n-1.2.1-r1.ebuild:2 app-i18n/koffice-i18n/koffice-i18n-1.3.ebuild:2 app-i18n/koffice-i18n/koffice-i18n-1.3.2.ebuild:2 app-i18n/koffice-i18n/koffice-i18n-1.3.1.ebuild:2 app-sci/mupad/mupad-2.5.2-r1.ebuild:2 app-sci/mupad/mupad-2.5.2-r2.ebuild:2 app-text/cstetex/cstetex-2.0.2.ebuild:2 dev-java/blackdown-jdk/blackdown-jdk-1.4.1.ebuild:3 dev-lang/ruby/ruby-1.8.2_pre2.ebuild:2 dev-lang/ruby/ruby-1.8.1-r7.ebuild:2 dev-lang/ruby/ruby-1.8.2_pre1.ebuild:2 *dev-libs/pcl/pcl-1.2.ebuild:2 dev-libs/uclibc/uclibc-0.9.26-r2.ebuild:3 dev-util/rhide/rhide-1.5.ebuild:3 dev-util/rhide/rhide-1.5-r1.ebuild:3 media-gfx/graphviz/graphviz-1.12-r1.ebuild:2 net-misc/ltsp-core/ltsp-core-4.0.ebuild:3 *net-p2p/sancho-bin/sancho-bin-0.9.4.5-r1.ebuild:2 *net-p2p/sancho-bin/sancho-bin-0.9.4.7.ebuild:2 *net-www/ci/ci-1.1.6.ebuild:2 *net-www/ci/ci-1.1.5.ebuild:2 net-www/opera/opera-7.11-r2.ebuild:2 *sys-apps/busybox/busybox-1.0.0_pre20040726.ebuild:2 *sys-apps/busybox/busybox-1.0.0_pre20040721.ebuild:2 sys-devel/gcc/gcc-3.3.2-r3.ebuild:6 sys-devel/gcc/gcc-3.3.4.ebuild:7 sys-devel/gcc/gcc-3.2.3-r4.ebuild:5 sys-devel/gcc/gcc-3.3-r1.ebuild:6 sys-devel/gcc/gcc-3.3.3_pre20040130.ebuild:6 sys-devel/gcc/gcc-3.3.3_pre20040408-r1.ebuild:6 sys-devel/gcc/gcc-3.3.ebuild:6 sys-devel/gcc/gcc-3.3.2-r5.ebuild:6 sys-devel/gcc/gcc-3.3.3_pre20040215.ebuild:6 sys-devel/gcc/gcc-3.3.3_pre20040322.ebuild:6 sys-devel/gcc/gcc-3.3.4-r1.ebuild:7 sys-devel/gcc/gcc-3.3.3-r4.ebuild:7 sys-devel/gcc/gcc-3.3.2-r7.ebuild:6 sys-devel/gcc/gcc-3.3.2-r2.ebuild:6 sys-devel/gcc/gcc-3.3.3.ebuild:6 sys-devel/gcc/gcc-3.3.1-r5.ebuild:6 sys-devel/gcc/gcc-3.4.1.ebuild:8 sys-devel/gcc/gcc-3.3.3-r6.ebuild:7 sys-devel/gcc/gcc-3.3.3-r1.ebuild:6 sys-devel/gcc/gcc-3.4.0-r6.ebuild:7 sys-devel/gcc/gcc-3.3.2-r4.ebuild:6 sys-devel/gcc/gcc-3.3.3-r3.ebuild:7 sys-devel/gcc/gcc-3.3.2-r6.ebuild:6 sys-devel/gcc/gcc-3.3.2-r1.ebuild:6 sys-devel/gcc/gcc-3.3.2.ebuild:5 sys-devel/gcc/gcc-3.3.3_pre20040426.ebuild:6 sys-devel/gcc/gcc-3.4.1-r2.ebuild:8 sys-devel/gcc/gcc-3.3.3-r5.ebuild:7 *sys-devel/gdb/gdb-5.3.90.ebuild:2 *sys-kernel/pac-sources/pac-sources-2.4.23-r11.ebuild:2 *sys-kernel/aa-sources/aa-sources-2.4.23-r2.ebuild:2 -sys-kernel/grsec-sources/grsec-sources-2.4.26.2.0-r7.ebuild:3 *sys-kernel/ck-sources/ck-sources-2.4.26-r1.ebuild:2 sys-libs/db/db-4.1.25_p1-r4.ebuild:2 sys-libs/db/db-4.2.52_p2.ebuild:2 sys-libs/db/db-4.1.25_p1-r3.ebuild:2 sys-libs/db/db-4.2.52_p1.ebuild:2 sys-libs/glibc/glibc-2.3.4.20040808.ebuild:2 sys-libs/glibc/glibc-2.3.4.20040619.ebuild:3 sys-libs/glibc/glibc-2.3.4.20040619-r1.ebuild:3 x11-base/xfree/xfree-4.3.0-r5.ebuild:2 x11-base/xfree/xfree-4.3.0-r7.ebuild:2 x11-base/xfree/xfree-4.3.0-r6.ebuild:2 x11-misc/macopix/macopix-1.0.4.ebuild:3 x11-misc/macopix/macopix-1.0.3.ebuild:2 *x11-wm/sawfish/sawfish-1.3.20040120.ebuild:2
Well, not all of them are invalid. Some ebuilds like gcc actually are static for one particular version. It is currently still allowed to have a SRC_URI that differs per version. If you look at the gcc ebuild the SRC_URI differs on the status of the package. This status is static for one ebuild. As such the cache results are consistent with the package. While I didn't check all ebuilds, there are probably a few that are actually broken. Also dev's make errors, but that doesn't mean that it is valid syntax or that it works (allthough it may seem to)
Ok, now i get the point. For each ebuild (version+revision) there should always be exactly one SCR_URI. This makes sense (but i still can't find this rule anywhere). As in my opinion LANGUAGE will be a constant on most systems, there would always be one unique SRC_URI. May I note that this rule was violated by xfree a few weeks ago (I just emerged -e world and a new patchset was downloaded for xfree, that means the SRC_URI must have changed without changing the revision numer...). I'm running stable xfree, i think unstable packages will change this way moe often. But I agree mistakes of others don't justyfy doing invalif things. So how can the dilemma been solved? The cleanest way would probably be to introduce a new ebuild openoffice-de (and maybe other languages too, if there are people interested). The original ebuild would more or less stay the same (maybe it should inform people that use LANGUAGE=049 that there is another ebuild with german helpfiles by using einfo?). Since the new ebuild and the original one will have a lot in common, it might be wise to introduce an openoffice.eclass? I am willing to write such an ebuild, but I won't start wasting my time (the current, invalid solution works fine for me...) if it has no future.
Move deprecated ebuild still being marked as LATER to Fixed.
