From: Darren S. <li...@yo...> - 2007-03-15 23:16:22
|
I demand that Carlos E. R. may or may not have written... > The Wednesday 2007-03-14 at 17:38 -0000, Darren Salt wrote: >>>>> ./gxine: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory >>>>> But it is there: >> [snip] >>>> Two ways: use LD_LIBRARY_PATH or symlink to one of them from /usr/lib. >>>> $ LD_LIBRARY_PATH=/usr/lib/xulrunner-1.8.1b2 ./gxine-test >>> I did this one and it runs, thanks. Maybe next time I log out and in it >>> will work without the hack. >> With the symlink in place, it'll Just Work anyway. Logging in again won't >> make any difference (or if it does, you have an odd system). > Just a hunch. If the environment changed after I installed that library, my > session will not have it till I log out and in. That depends on which parts of the environment. You're right about things like group membership; but changes which affect ld.so will be seen immediately. > I'll tell you when I do log out next time, and is not often if I can avoid > it (I suspend to disk, so the session stays). :-) [snip] >>> Mmm! I just found a bug. After running gxine, zapping (tv viewer) can not >>> display in overlay mode (shows a pink square). xine-ui does the same only >>> when it crashes or gets killed. Situation reverts on log out. >> That could be due to the Xv auto-paint setting. If >> $ xvattr -a XV_AUTOPAINT_COLORKEY -v 1 >> helps then, while it could be argued that gxine (or xine-lib) should be >> resetting that, I'd say that zapping should be setting it as *it* needs >> it. > Yes, that did the trick. Found and old copy in my directory, and it > worked. This is good... > I guess zapping doesn't set it thinking that some other program has > "whatever" in use. Dunno, I'm just a user ;-) It just assumes that what it needs is already set up. Broken behaviour, I'd say... >>> But I would like to have "...man/es/Makefile.*" files, too - or tell me >>> what variations have to be made to them, simply copying them over from >>> the en dir doesn't work. Those files are needed so that the man pages get >>> installed: I am looking at them using "mc" - and editing them using >>> "mcedit", didn't guess it would be so easy... >> doc/man/es/Makefile.am is publicly visible now. > Let me see... mmm, no; as I'm in lazy mode, I'm not using cvs, but the > browser, looking at: > <http://xine.cvs.sourceforge.net/xine/gnome-xine/doc/man/#dirlist> > there is only 'en', and 'de' directories. Perhaps it takes a day to > propagate, or I'm looking at the wrong place. I do occasional batch updates of the CVS repository. <URL:http://zap.tartarus.org/~ds/hg/gxine/> is up to date; I'll update <URL:http://zap.tartarus.org/~ds/hg/gxine-0.5.x/> soon. [snip] >>>>> So be careful if you do clean them up, because a single comma may >>>>> require half an hour translation job ;-) >>>> It depends. It could be, a comma which shouldn't be there... :-) >>> A single comma more or less means that the source string does not match >>> what the *.po files contains, so that the string is rendered in the >>> original language, not the translated ones. >> It may well be safe to tweak the source strings in the .po files. I'd say >> that it definitely is for a simple spelling mistake such as "occured". > Ah! Yes, yes, that wouldn't break translations. I found a few of those > errors, by the way. That doesn't surprise me - unless they're in gxine... >>> And worse for the translator, the old translated string is lost from the >>> .po file, too: so the sentence has to be typed from scratch, unless the >>> fuzzy translator catches it. >> Well... "make po gxine.pot-update" generally works well enough, marking as >> fuzzy or commenting out with "#~". > Ah, you got a make rule for it. Nice :-) Actually, it's "make -C po gxine.pot-update", but "make translator" will take care of it. > [...] > And I see that gxine contains notes for the translator: well though that! > Often I have doubts about how much space do I have, whether size is limited > (dialogs and windows), and such... Mostly, they'll be expanded by the UI toolkit to accommodate the message. If not, then there's probably a bug :-) > I don't know till I run the program and see it come out bad - if possible, > sometimes I don't know how to make the program display certain message. > So comments to the translators do help ;-) Definitely. Some comments were added as a result of translation problems... I should add a few comments for those which appear on the console, but mostly it won't matter if they aren't wrapped at 80 columns. > And a place to put our names! Now, that's nice O:-) Once you've done that and installed the translation, have a look at the about dialogue box... > Mmmm... > I'll have to find out if the "license" part has been already translated by > somebody somewhere... I'm not a lawyer, and legalese is tricky. I prefer > not translating those things myself. Not binding, you know. <URL:http://www.gnu.org/licenses/translations.html> -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Someone is speaking well of you. How unusual! |