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

[Darren S. <li...@yo...>]

I demand that Carlos E. R. may or may not have written...

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

Fair enough :-)

[snip]
>>> 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 ;-)

I'm currently using a mix of xfce 4.3.99.2 and 4.4.0 with a hint of
rox-filer...

[snip]
>>> ./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).

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

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

doc/man/es/Makefile.am is publicly visible now.

> I attach gxine.1 now.

So's that.

[snip]
>>> 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).

<AOL>.

> Yes, it needs some effort: create the token, edit the string in another
> file... just typing ahead in the same source file is easier.

Very true...

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

Let's just say that compiling with --Wformat=2 is preferred :-)

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

True *but* that will get in the way of normal translation - you can be sure
that some translators will not notice that, and translate the strings as
presented in <locale>.po (*.pot) instead.

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

> 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 "#~".

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

Ruling a big country is like cooking a small fish.