From: Daniel Stenberg <daniel_at_haxx.se>
Date: Tue, 29 Apr 2003 18:22:18 +0200 (CEST)

On Tue, 29 Apr 2003, TP Diffenbach wrote:

> I'm only considering depending on the order of strings that "should" be
> ordered: all the options for a particular setting, from the first option
> through to the last option. I'll still index into language_strings via the
> enum constant on teh first one. Of course, I'll also be relying on the
> number of strings in the series. (Perhaps the .lang file could be modified
> to indicat this, and the .lang handling scripts modified to generate an
> enum constant for this too.)

I am only for this kind of operation if the lang system is written to
maintain order and gapless state among such 'enums' and similar. As things
are now, if we figure out that item 5 out of 10 items is unnecessary, we
simply blank it and it won't be used in the software but there will be a
blank position.

Simply assuming this won't happen is like begging for trouble, if you ask me.

> This additionaly allows us to write .cfg files in the user's curently
> selected langauge, and, as the language file entry is prior to any
> translated settings in the .cfg, to read .cfg files in any langauage for
> which we can load the lanaguage file. Code will have to be added to abort a
> .cfg load if the approproate lanaguage file cannot be loaded, and to so
> inform the user.

I have two main arguments against translated config files:

1. When I've change language and don't keep the previous language file
   around at the correct place, I can't load my own older config files
   anymore?

2. I can't interchange config files with my friends, or even post them in bug
   reports and have the developers understand them. Reading them becomes a
   pain, and I think one of the main reasons for having them in plain ASCII
   is to keep them readable.

> Further, by getting hard-coded English strings out of settings.c, we get
> rid of having two copies of each hardcoded string, one for read and one for
> write (unless the linker combines equal strings? Does gcc really optimize
> that well?), plus whatever strings are used in the user interface settings
> screens. This will save a good deal of code/data space in the .ajz.

The existing translated phrases won't cover the settings keywords all the
way, so you'd need to add a bunch of new ones there too.

> So we gain .cfg files translated on write and on read

I think its a lose.

> we save space by having only a single copy of each string in memory, and
> it's all legal C.

We should work on that differently, IMHO.

> We lose the ability to reorder strings in the .lang file which naturally
> should be ordered anyway (and any re-ording causes us to bump a version
> number, so it's not likely to happen often or mistakenly).

Re-ordering won't happen no, but perhaps we stop using one and cause a gap.
Such gaps aren't filled again until we bump the language file version number
(which so far never has happened).

-- 
 Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/

Received on 2003-04-29