From: TP Diffenbach <rockbox_at_diffenbach.org>
Date: Sun, 25 May 2003 17:31:10 -0400

I've written a new version of genlang.

For language file entries in the current format, it produces the same output as the current genlang.

The modified genlang can be found at:
http://www.diffenbach.org/rockbox/genlang

However, it also proceses language files where an entry can have multiple strings, in this format:

id: LANG_WEEKDAY
desc: Maximum 3-letter abbreviation for weekday
eng: "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
new:

If multiple comma-seperated strings are encountered on the "eng:" line, each is given an id in the form id_N, where N is a two digit offset number beginning at 00. Additionally, a #define in the form id_COUNT is added to lang.h with the total number of strings

The above example would produce enums LANG_WEEKDAY_00 through LANG_WEEKDAY_06, with LANG_WEEKDAY_00 specifying "Sun", etc., and a #define LANG_WEEKDAY_COUNT 7

The strings are guarenteed to be ordered and contiguous, so to find the third weekday, at offset 2, one could use:
   &( str( LANG_WEEKDAY_00 ) )[ 2 ]
or one could pass the entire array, and its count with
   (char**) &( str( LANG_WEEKDAY_00 ) ), LANG_WEEKDAY_COUNT
to allow the called function to index into the string.

Of course, it is probably useful to define some macros to relieve the programer the effort of balacing these parentheses and casts. (The cast is required because language_strings is an array of pointers to unsigned char, while most functions take a pointer to char or a pointer to pointer to char (char**).)

Allowing multiple strings in an entry is useful because we have a lot of code that declares local arrays of str() indices, just in order to manipulate what should already be an array, that is some slice of the language_strings array. This is tedious and error prone, and wastes code space as well as programmer effort.

It also allows use not to tediously repeat lang file entries, and indicates to translators and maintainers what language strings are related entities.

It will also allow us to make settings code more generic and less specialized, again allowing for less code and more code reuse.

As far as translating is concerned, the number of strings specified in the english.lang file is controling. If a translation adds more strings to the "new:" line entry than are in the "eng:" line, the additional strings are ignored. If the translator provides fewer, the remaining are copied form the "eng:" line. If the translator provides a "translation" that is the empty string (""), the "eng:" entry is used.

Examples:
id: LANG_STUFF
desc: Three strings descibing foo, bar, and baz
eng: "foo", "bar", "baz"
new: "efoo"

In this case, the "translated" strings are "efoo", "bar", "baz"


id: LANG_STUFF
desc: Three strings descibing foo, bar, and baz
eng: "foo", "bar", "baz"
new: "efoo", "ebar", "ebaz", "whoof"

In this case, the "translated" strings are "efoo", "ebar", "ebaz"

id: LANG_STUFF
desc: Three strings descibing foo, bar, and baz
eng: "foo", "bar", "baz"
new: "", "ebar", ""

In this case, the "translated" strings are "foo", "ebar", "baz"


Please let me know what you think.

Thanks,
Tom

-- 
Archos FM has a Rockbox!

Received on 2003-05-25