Re: [Xmltv-devel] simple minded

[Davide C. <pi...@in...>]

> Is this worth the time? The work will mostly be done by the
> translat=
ors. I'm not sure how much benefit there really is, the
> listings langu=
age will not change. What do the PVR projects do?
> Personally I don't t=
hink the work outweighs the benefits, but what can
> I say, I'm an Ameri=
can. ( internationally self-centered )

I think this is the main questi=
on. For me translating every grabber
in every language would be too time=
 consuming and also complicated (as
you said, i would need external tran=
slators besides the devs, and
that means a translation framework nightma=
re).

For me, the only thing a grabber needs is it's original language.=
 
For example, right now there are italian users that grab italian
data=
 using a program that is completely in english. That doesn't
make much s=
ense to me, especially when I am asked very simple
questions that are an=
swered in the docs - this is obviously a case
where the user doesn't spe=
ak english very well, or not at all.

Also, as we were discussing earli=
er, if a user wants to grab
german or french data, I would assume he cou=
ld speak french and
german, and that he could understand messages and do=
cs.
Or if I, for example, want to grab data for another country just
fo=
r testing purposes (maybe helping a new dev in developing a 
grabber?) I=
 could just revert to english, as at least between
us developers it seem=
s to be the common language.

>One thing to keep in mind if you wanted =
to add languages to various
>grabbers, is that XMLTV is a collection of =
mostly independent programs.

>The additional language support would ha=
ve to be optional and need to
>be easily removed. Someone other than the=
 author would typically
>maintain the translations.

This sounds like =
a nightmare to me...
In a two-languages solution everything can also be =
handled by the
developer himself.
This wouldn't even be an issue if it =
was just for the messages: every
developer could come up with his soluti=
on. The tricky part is when
we get to the common ground, i.e. new depend=
encies and Makefile.PL (to 
install man pages).

> Re: Man pages.. how=
 do other projects deal with this?
I don't know but installing the man p=
ages in the localized directories
sounds good enough to me, it would the=
n be up to man to use the right
one.

>Re: Pod docs... how do other pr=
ojects deal with this? One possibility
>is to use the *.PL preprocessed =
to set the POD language at "make" time.
>Maybe include multiple POD sect=
ions in the ".in" file and cut out the
>other languages.
or just skip i=
t altogether, and just internationalize the man pages, as
that would be =
what most users would use anyway. We could keep the english
pod with a n=
ote saying for example that italian docs can be viewed with man,
or mayb=
e found in a readme.it file in the share dir?

>David, I think you open=
ed this can of worms... which grabber do you
>propose internationalizing=
 as a trial? Do you want to do it?
sure, no problem with that.

ciao=0D
=
davide=0A=0A=0A=0A_______________________________________________________=
_____=0ANavighi a 4 MEGA e i primi 3 mesi sono GRATIS. =0AScegli Libero A=
dsl Flat senza limiti su http://www.libero.it=0A