Re: [xine-devel] How do I submitt .po translation files?

[Carlos E. R. <car...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Wednesday 2007-03-14 at 00:56 -0000, Darren Salt wrote:

> > You mean that you want gxine translated?
> 
> That's entirely up to you. I mention it because you're currently showing
> interest in doing translations for other xine project packages...

True enough. But I can't translate all of them, and I'm sure there are 
many packages deserving translations. I'll have a go, anyway.

I told kbabel to do a rough translation (based on xine-ui es.po), and _it_ 
has been running 12 hours at least, three more messages to go. No, it just 
finished:

  567 edited entries
   22 (3.88% ) exact translations
  448 (79.01%) approximate translations
   97 (17.10%) nothing found

The quality of the "fuzzy" strings is way too bad, unfortunately.

> 
> > Well, I only have xine-ui on my system. You mean that gxine will be the
> > preferred front end, and xine-ui will be deprecated?
> 
> No; it's just a different front end.

Ah, ok.

> > Dunno, but then others may ask for the kde translation too. xine-ui is
> > independent ;-p
> 
> You seem to be under the misapprehension that gxine is a GNOME app... ;-)

Yes  X'-)

I use gnome for my desktop, but my crowd uses kde. I use SuSE, you see ;-)


> Fine - most of that will work with 0.5.8 and current -dev.
> 
> >    I'm downloading it right now, I'll try to compile it and see how many
> >    messages are there.
> >    [...]
> >    Argh! There is not even an es.po file!
> >    [...]
> 
> Yes. I wouldn't have asked had there been one which was reasonably
> complete...


I had to find out how to create a new es.po file first ;-)


> 
> [snip]
> > ./gxine: error while loading shared libraries: libmozjs.so: cannot open
> shared object file: No such file or directory
> 
> > But it is there:
> >   /opt/netscape7.1/libmozjs.so
> >   /usr/lib/firefox/libmozjs.so
> >   /usr/lib/thunderbird/libmozjs.so
> >   /usr/lib/xulrunner-1.8.1b2/libmozjs.so
> >   /usr/local/mozilla/libmozjs.so
> 
> 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.


> (gxine-test lets you run gxine without having to actually install it. It's
> really meant for debugging, though; run that way, it may not handle
> translations well.)

Actually, I tried that way first, then I installed to see if it was the 
problem. Then I asked :-)

[...]

Cute, the predefined medias menu! I'll have to try that one later.


   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.



> >   (Attached goes an appetizer: gxine_client.1 in Spanish)
> 
> Committed. It's not yet publicly visible, though :-)

Fine :-) 

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...

I attach gxine.1 now.



> [snip]
> >>> (some of those messages in xine-lib are a page long, did you know? )
> >> And they need some cleaning up... :-)
> 
> > And English is a "concrete" language, when translated to Spanish it usually
> > takes more words. Some of the "help tips" push below the bottom of the
> > screen and can not be read completely, as they can not move. I have to move
> > the ui and then hope they display inside the screen.
> 
> Ouch. That'd be a UI bug, I think.

I guess so.


> > By the way... AFAIK, changing a single word of the original English text
> > renders the translation to all languages useless, due to the gettext
> > system... if messages were based on tokens, there would be no danger.
> 
> This is true... OTOH, token-based systems have certain disadvantages: format
> specifiers tend not to be included in the token names. Not including them
> makes for a certain amount of difficulty in checking for parameter
> mismatches. (It is possible, though. It's just not straight-forward and it
> requires source modification.)
> 
> BTW, I've used a token-based system before (messages files on RISC OS).

Me too, with turbo pascal (I have never programmed anything "serious" in 
linux, there are many many things I don't know). Yes, it needs some 
effort: create the token, edit the string in another file... just typing 
ahead in the same source file is easier.

Ah, I see what you mean about the format specifiers... yes, printf and 
family... Uff, nasty. Errors could easily creep in.


Another hack would be creating/modifying the en.po instead, leaving the 
source string alone. Not nice, though. But you might consider that for the 
help tips and verbose logs.


> > 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.

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.

- -- 
Cheers,
       Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFF9/v8tTMYHG2NR9URAi9tAJ9CwEE6UqDeQzIixhrPM35SS8Mk0gCdEmh7
ov3WEIRUm4WGvNy2IAa9Hc4=
=dPSH
-----END PGP SIGNATURE-----