rollercoaster@xxxxxxxxxxxxxxxxxxx wrote:
> Am Montag, 14. November 2005 18:06 schrieb Lucian Muresan:
>> > That was something that was missing in vdr. Thanks.
>>
>> Well, according to Klaus' answer, apparently not...
> Well, seems that Klaus and I have different views on this. :)
>
>> Well, for distributors, yo're right, I didn't think of those. But these
>> files where meant to be user-configurable anyway, I think, so users
>> wouldn't need to update that many files.
> Ok, but an end-user usually won't use different languages in his vdr-box, so
^^^^^^
Yes, I'd emphasize ^^^^^^.
> in this case Klaus would be right... ok, no rule without exceptions,
> otherwise you would not have written this patch, but i will keep this aside
> for now.
Yes, I'm one of those who occasionaly change languages from the OSD
Setup Menu. If I'm allowed to joke, others, ther could be an option to
make that entry unavailable after they set their language once, and
never change it again ;-).
So, joke aside, if changing the whole OSD language is possible
on-the-fly, like on most of modern consumer electronics products (and
VDR too emulates and even outperforms a consumer electronics family,
STBs) like even digital cameras or DVD players or what else, it appears
to me only consistent if all OSD pages *can* change (the must not, other
equipment may also have user-configurable menu entries and leve that to
the user). But if there is a way to achieve something due to the open
architecture, and that something is achieved *whithout* changing the
default (previous) behaviour like in the case of this patch, I don't see
any serious reasons beeing against it. This patch is not meant to burden
the main developer, as it introduces some *optional* extension. The
original functionality didn't burden him either (I didnt find any
commands.conf or reccmds.conf in vanilla VDR source distribution), so
it's a feature which the Klaus intentionally left beeing the user's
problem. Now I'm asking again, if the patches only gives a new
possibility, but doesn't *force* anyone to use it, what's the problem?
>> Anyway, what does the
>> distributor do about inconsistent/incomplete translations in VDR's own
>> i18n.c file, as with adding new features it'S impossible to have all
>> translators update all strings, and no one delays a release just because
>> of that.
> you're right, that's really a problem. but at some point you will have to
> start a translation, maybe if you come to a first beta or so, even if the
> translation will alway behind the current development.
>
> What concerns me more, is how to let the translators do the translation of vdr
> and all these plugins (currently 25 in our distribution). It will be quite
> unhandy to send them 26 file to be translated and syncing them after
> translation, so i already think of merging them for easier handling. But
> after that it will be harder to care for updates...
I can believe you that this is hard to maintain for a distributor. But
hey, I just hacked something which makes it possible, now you want all
your work done, too ;-). Now I looked better at your email address, so
you're packaging this for the ReelBox, so VDR is even helping you making
money :-). Is it actually available?
> Seems like it's time for some concept. If anyone has got ideas...
> btw: I also like the concept like in kde (i.e.) of having installable language
> files.
Overdue, and I agree with you that this should be solved more elegant
(something like gettext comes to mind), but there are other problems
needing concept, too, and only Klaus decides what's important to *him*.
Sorry, but that's the way it looks like, I only dare to remind of UTF-8
(he doesn't need different languages, or other encodings than
ISO-8859-1[5], etc.), NPTL just to name 2 of them, but this has all been
discussed and it makes little sense, I think.
Lucian
