|
Rockbox mail archiveSubject: Re: Misc questions + fading patchRe: Misc questions + fading patch
From: Remo Hofer <remo.nospam_at_gmx.net>
Date: Fri, 22 Aug 2003 15:04:38 +0200 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. Received on 2003-08-22 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |