load i18n versions of commands/reccmds.conf

  Hi,

I'd like to propose a patch for further i18n of VDR, namely in the
commands.conf and reccmds.conf files. Even if any user can customize
these files to his whishes (and language), I think that it is more
consistent from the VDR user interface point of view if the commands
defined there also change their language on the OSD, according to the
OSD language setting.
All that the user has to do, is to provide, additionally to the "normal"
files commands.conf and reccmds.conf, the version(s) in the language(s)
he want's to use as commands.conf.xyz and reccmds.conf.xyz, where ".xyz"
is the 3-characters language code defined in VDR's i18n.c:

  // The 3-letter names of the language...
  { "eng,dos",
    "deu,ger",
    "slv,slo",
    "ita",
    "dut,nla,nld",
    "por",
    "fra,fre",
    "nor",
    "fin,smi",
    "pol",
    "esl,spa",
    "ell,gre",
    "sve,swe",
    "rom,rum",
    "hun",
    "cat,cln",
    "rus",
    "hrv",
    "est",
    "dan",
  },

Important notes:
- There is *no problem* if VDR does not find such translated command
files at startup or at OSD language switching on the fly, it will always
fall back to the default and if those are missing, as you  already know,
it's not a big deal either, so the behaviour doesn't change (except that
there is a syslog message if such a customized file hasn't been found,
just to inform users who are reading the logs, that *they could have*
multiple command file versions according to configured OSD language, for
english setups it#s absolutely silent as before);
- this will only work with the *first* name for languages where multiple
3-letter names are defined;
- As english is all over in VDR's source code specially treated, this
makes no exception here, so it's indeed treated specially: english files
need *no* such 3-letter extension, and are *only* loaded in their
default form.

Have phun,
Lucian
  

Lucian Muresan wrote:
> Hi,
> 
> I'd like to propose a patch for further i18n of VDR, namely in the
> commands.conf and reccmds.conf files. Even if any user can customize
> these files to his whishes (and language), I think that it is more
> consistent from the VDR user interface point of view if the commands
> defined there also change their language on the OSD, according to the
> OSD language setting...

The commands files are typically written by the specific users
themselves, so I would assume they write these in _their_
language and that's it.

I don't think that this feature is necessary, it only makes
things needlessly complex, because then you would have to
maintain numerous copies of your commands files, and any
changes you make would have to be done in several files
instead of a single place.

Klaus
  

Am Montag, 14. November 2005 14:22 schrieb Lucian Muresan:
> I'd like to propose a patch for further i18n of VDR, namely in the
> commands.conf and reccmds.conf files. Even if any user can customize

That was something that was missing in vdr. Thanks.

> All that the user has to do, is to provide, additionally to the "normal"
> files commands.conf and reccmds.conf, the version(s) in the language(s)
> he want's to use as commands.conf.xyz and reccmds.conf.xyz, where ".xyz"
> is the 3-characters language code defined in VDR's i18n.c:

Although this is really easy to install for a user, it will be hard for an 
admin/distributor to keep these files in sync. As of vdr currently supporting 
up to 20 languages, one would have to edit up to 20 files just for a minor 
change (even if it just affects the command line itself).
Wouldn't it be cleaner just to have _one_ config file and one for the 
translations?

regards,
Thiemo
  

Am Montag, 14. November 2005 17:24 schrieb Klaus Schmidinger:
> Lucian Muresan wrote:
> > Hi,
> >
> > I'd like to propose a patch for further i18n of VDR, namely in the
> > commands.conf and reccmds.conf files. Even if any user can customize
> > these files to his whishes (and language), I think that it is more
> > consistent from the VDR user interface point of view if the commands
> > defined there also change their language on the OSD, according to the
> > OSD language setting...
>
> The commands files are typically written by the specific users
> themselves, so I would assume they write these in _their_
> language and that's it.

I don't agree. In many cases these files are written by a distribution 
maintainer, so it is neccessary to have everything in vdr translated.
But maintaining 20 files that all have the same functionality will be a 
pain...

regards,
Thiemo
  

Klaus Schmidinger wrote:
> Lucian Muresan wrote:
> 
>>Hi,
>>
>>I'd like to propose a patch for further i18n of VDR, namely in the
>>commands.conf and reccmds.conf files. Even if any user can customize
>>these files to his whishes (and language), I think that it is more
>>consistent from the VDR user interface point of view if the commands
>>defined there also change their language on the OSD, according to the
>>OSD language setting...
> 
> 
> The commands files are typically written by the specific users
> themselves, so I would assume they write these in _their_
> language and that's it.
> 
> I don't think that this feature is necessary, it only makes
> things needlessly complex, because then you would have to
> maintain numerous copies of your commands files, and any
> changes you make would have to be done in several files
> instead of a single place.

Taking out the syslog stuff from the patch would really keep everything
transparent to users who don't use to switch OSD languages, they can
continue to use the normal commands.conf and reccmds.conf for the
language _they_ wish and never change the OSD language setting if they
don't need or want to, so they really do not have to maintain numerous
copies of those files, just their (either with, or without the 3-letter
language name, as the one without is used anyway as a fallback).

But some users do switch from time to time the OSD language , that was
the whole point, not to bother users who don't want to change their
habits, having them write and maintain multiple files, but only
providing the posibility for those who need it. Those even wouldn't have
to maintain 17 languages, maybe only one or very few.

For example, I have to switch them mainly because VDR lacks UTF-8
support, not because I wouldn't come along with english or german OSD, I
do not need the OSD in romanian for anything else than having displayed
EPG information (and names derived from it in recordings, DVD archives)
in the correct character encoding.

And I am also curious what's so complex about that patch, it only
extends the i18n scheme (you're doing in fact the same too, try to
translate the standard english string into the specified language if
available, if not, leave it as it is but also log that "no translation
found" message) to the user-supplied commands files. Maybe the patch is
not perfect, but it's small enough to be reviewed and evaluated by
anyone, and it can also be completely silenced if no logging is wished.
I tried to do it as minimal invasive as possible, and those different
languages files would really remain the user's business to maintain, I
don't think somebody would want to have all 17-20 possible languages.

Lucian
  

rollercoaster@reel-multimedia.com wrote:
> Am Montag, 14. November 2005 14:22 schrieb Lucian Muresan:
> 
>>I'd like to propose a patch for further i18n of VDR, namely in the
>>commands.conf and reccmds.conf files. Even if any user can customize
> 
> 
> That was something that was missing in vdr. Thanks.
> 

Well, according to Klaus' answer, apparently not...

>>All that the user has to do, is to provide, additionally to the "normal"
>>files commands.conf and reccmds.conf, the version(s) in the language(s)
>>he want's to use as commands.conf.xyz and reccmds.conf.xyz, where ".xyz"
>>is the 3-characters language code defined in VDR's i18n.c:
> 
> 
> Although this is really easy to install for a user, it will be hard for an 
> admin/distributor to keep these files in sync. As of vdr currently supporting 
> up to 20 languages, one would have to edit up to 20 files just for a minor 
> change (even if it just affects the command line itself).
> Wouldn't it be cleaner just to have _one_ config file and one for the 
> translations?
> 

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. 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.
On the other hand, a different approach, to have the translations
separated from the commands would have been better, but more complicated
to achieve (parsing of the files must then be rewritten for theese two
files, and I was trying to keep it as simple as possible)...

Lucian
  

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

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

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.

thiemo
  

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
  

Am Montag, 14. November 2005 19:34 schrieb Lucian Muresan:
> rollercoaster@reel-multimedia.com wrote:
> > 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 ;-). 
No, i don't want anyone to do it this for us, I was just thinking loud.
This has to be done at sooner or later, so if it's not there *we* will do it. 
So i was asking if anyone has ideas or suggestions:

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

maybe it was unwise to do this question in this thread (as it does not concern 
your patch directly). But why not discuss this issue here on this list 
*before* starting work?

regards,
Thiemo
  

rollercoaster@reel-multimedia.com wrote:
> Am Montag, 14. November 2005 19:34 schrieb Lucian Muresan:
> 
>>rollercoaster@reel-multimedia.com wrote:
>>
>>>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 ;-). 
> 
> No, i don't want anyone to do it this for us, I was just thinking loud.
> This has to be done at sooner or later, so if it's not there *we* will do it. 
> So i was asking if anyone has ideas or suggestions:
> 
> 
>>>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.
> 
> 
> maybe it was unwise to do this question in this thread (as it does not concern 
> your patch directly). But why not discuss this issue here on this list 
> *before* starting work?
> 
> regards,
> Thiemo

Just for the record: I'm not going to implement language files in
version 1.4, but maybe will do so in version 1.5.x.

Klaus
  

Hello there, 
I also made some thoughts about the i18n problem. 
If we add some other languages e.g. it would blow the i18n.c 
up anyway. 
At First we should sort a little  the languages for
central Europe, nordic, latin and eastern languages:

{ "English",
    "Deutsch",
    "Français",
    "Italiano",
    "Català",
    "Español",
    "Português",
    "Dansk",
    "Nederlands",
    "Norsk",
    "Svenska",
    "suomi", // Finnish (this is not a typo - it's really lowercase!)
    "Eesti",
    "Polski",
    "Slovenski",
    "Magyar",  // Ungarisch
    "Hrvatski", //Kroatisch
    "Românã",
    "ÅëëçíéêÜ", // Greek
    "ÀãááÚØÙ", // Russian
  },

and name it as  i18n_euro, so we could add an i18n_asia.c or so. 
maybe a little perl script /vim rec could do this sort.

regards movimax


>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

Markus Hahn wrote:

> and name it as  i18n_euro,

'euro' as European Union or Europe geographically or
maybe Continental Europe (drop the useless islands) :)

Just grab ISO 639-2 and use them all.