Rockbox mail archive
Subject: Re: language and spearch for plugins
From: BlueChip (cs_bluechip_at_webtribe.net)
At 22:02 10/06/04, you wrote:
>On Thu, 10 Jun 2004, BlueChip wrote:
> > 1. Make lang.h readily available to the plugins, probably via plugin.h
> > You may need to add a similar version control system as the plugins
> > Personally I wouldn't bother, as if you DO change the lang file(s) you
> > risk killing all .voice files that exist.
>For language strings?
more for talk() than anything else.
>So the single language file should contain strings for all current and
>thinkable and future plugins?
no-one is ever going to create a .voice file with all speech in it, we just
don't have the RAM.
So no, I think that people should do what I have done, choose carefully and
get something that comes as close to being helpful as possible. For
example, Rockbox cannot say "centre" so I got it to say "balance 0" instead
...there is no word "fundamentals versus harmonics" so I chose "mdb balance"
>Won't that make it an unusable system very soon? I think it would. It
>sounds like a bad idea. I would rather have a system that better make the
>language strings for a particular plugin
>more separate and independent.
Now language support for plugins is a very different issue.
What would be realy nice is a sepereate file for each plugin "othelo.lang",
then some cool-and-doody build process that combines all the files and
strips any duplicates out.
Bet then where does it live? plugin ram, main ram, hmmmm ...maybe one each
is better -load as required WITH the plugin?
>I want Rockbox to be able to work with an
>unlimited number of plugins, each with their own set of language strings.
the drawback is that dupes will be stored; the drawback of not storing
dupes is that you have to load the whole language file for any one
plugin. got a coin?
>For the talking? If so, we would make a certain plugin-API version require a
>certain voice-file version. I don't like this idea either.
No, if strings are always added to the end (of either half LANG/VOICE) then
no earlier plugins will be effected :) Permanent backward compatability :)
>I would rather have
>the plugin API offer some kind of talk function that translates the ID used by
>a plugin to the ID that might be used internally, as then that function could
>be voice-file version aware etc.
That's certainly another way to achieve it, bit more memory hungry a lookup
table to a lookup table with a 1->1 relationship, wouldn't be my first choice.
>I haven't figured out the details of any of these points, and that's why I ask
>for help on ideas on how this is done the best way!
Well, I can't guarantee my way is best, but it should be good food for
> Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/
Page was last modified "Jan 10 2012" The Rockbox Crew