rollercoaster@reel-multimedia.com 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