dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: language and spearch for plugins

Re: language and spearch for plugins

From: BlueChip <>
Date: Fri, 11 Jun 2004 02:39:26 +0100

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
thought :)


> Daniel Stenberg -- --

Received on 2004-06-11

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy