Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Misc questions + fading patch
From: Remo Hofer (remo.nospam_at_gmx.net)
Date: 2003-08-22


Eric Lassauge wrote:

>> -----Message d'origine-----
>> De : owner-rockbox_at_cool.haxx.se [mailto:owner-rockbox_at_cool.haxx.se]De la
>> part de Daniel Stenberg
>>
>> On Thu, 21 Aug 2003, Eric Lassauge wrote:
>>
>> > - messages in plugins: what is the prefered (?) method for
>> translating the
>> > messages in the plugins: main .lang file (and use the str()
>> function in the
>> > plugin code) or a lang file for each plugin ? I think nothing
>> was said on
>> > the list for that.
>>
>> I don't think anyone has cracked this nut yet. We don't want to
>> pollute the
>> main language file with plugin-related strings, and having one
>> language file
>> for each plugin seems a bit excessive in my eyes...
>
> OK, now it could be the time to take a decision. Perhaps a lang
> file for all the plugins ?

What's the benefit? If you put the strings of all plugins into one
file this could as well be the main language file. I'd say one file
for all strings (including pluggins) or one per plugin.

If we put all the strings in one file, the plugin would not only depend
on the api revision but also on the "language revision", because the
english default strings would be linked to the main binary.

Maybe we have to extend the language system, so that the default strings
 are linked to the individual plugin/binary but can be overwritten by
one or several language files.

I would not like a system, where every plugin comes with several
language files. This would clutter up the .rockbox directory and the
work for the translators would not be easier as well.

But if we put all strings into the main language file, then the plugin
authors of plugins already in cvs would net write acces to code
"outside" their plugin. And plugins not yet in cvs would not have acces
to the strings at all.

>> > - several strings are #defined or hardcoded in the code in
>> several places:
>> > for example:
>> > - favorites.h: FAVORITES_FILE ,
>> > - playlist_menu.c:DEFAULT_PLAYLIST_NAME,
>> > - tree.c:"root"
>>
>> > Is'nt it better to have them in the lang file or in the configuration
>> > options ?
>>
>> They must not be in language files, as they are not language dependent.
>
> I didn't agree 'Favorites.m3u' or 'dynamic.m3u' is not language
> independent... I personaly changed these strings in the code :->
>
>>
>> I would say they *could* be made configurable, but that come at a price.
>> What's the benefit of doing it?
>
> Why not :->

I hate translated path names, identifiers in programming languages,
option values etc. as we can see it in other operating systems. Imagine
the words in the config files would also be translated. We would have
incompatible config files depending the language loaded. If a filename
(or similar) is hard coded into a program it should be the same for
every language. Otherwise make it user selectable.



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa