On 2005-06-07, Michelle Konzack <dos4michelle@freenet.de> wrote:
> Am 2005-06-07 01:05:13, schrieb Grzegorz Adam Hankiewicz:
> > On 2005-06-03, Michelle Konzack <dos4michelle@freenet.de> wrote:
> > > Thats interesting, because I have not found the "language.dat"
> > > in the Allegro packages of Debian GNU/Linux
> >
> > The poor documentation just mentions language.dat in a few places
> > but there is no instructions as to what this file means, what
> > it is for, and how *nix administrators should deal with it, just
> > like the keyboard.dat file or the setup program, meant to be used
> > by the administrator to create the global /etc/allegro.cfg. [...]
>
> [...] Do you will file the to BUGs for the documentation and
> the language.dat ?
Ok, let's remember all the facts:
Miriam Ruiz is packaging the game Kraptor for Debian, and finds that
language.dat is meant to be an Allegro generic file instead of a
game specific file with game strings. Proposed hacks are hijacking
of ALLEGRO env in 4.0 or use of set_allegro_resource_path() for
the yet to be released 4.2.
Both solutions are wrong from a global point of view, because Allegro
and game specific strings are mixed in the same .dat file. This
means that when the Allegro library is updated, it will still use the
possibly outdated strings found in the game provided language.dat. If
possible, the system Allegro package should come with a language.dat
and user programs should provide their translations separately.
However, this is technically not possible, because Allegro
doesn't support overriding one dat file with another. Such storage
mechanisms are only planned, and not even sure to be included for
Allegro 4.3 and above (if that version is reached). Luckily, since
3.x days Allegro provides the functions override_config_file()
and override_config_data() which can help in this situation, by
putting more burden on the user program.
Let Kraptor use an Allegro provided language.dat file,
and Kraptor provide separate game specific xxtext.cfg
files. This is, if Kraptor's language.dat contains estext.cfg,
entext.cfg and frtext.cfg, store those files separately in
/usr/games/kraptor/xxtext.cfg.
Then, in Kraptor's code just before the call to
reload_config_texts("xx") new code has to be inserted. This
code will use get_config_string("system", "language", "EN") to
find out the currently selected language of the user. With the
obtained language code a path can be constructed in the form of
/usr/games/kraptor/xxtext.cfg and override_config_file() used on it.
Thanks to override_config_file(), Allegro will be using both a
global language.dat file provided by its own package, and the
specific language resource overridden by Kraptor. In order to show
how this mechanism works I have attached a very simple example which
should demonstrate the effects of override_config_file(). For me
the output is:
1 - Eje , How are you?
2 - Aim , Blahblah uno
3 - Aim , Special 1
4 - Blah special 2 , Blahblah uno
5 - Blah special 3 , Blah special 3
1 mixes Spanish (my global system setting) and a game custom string
not found anywhere. 2 uses frtext.cfg in the test directory,
showing how to change the language to French at runtime. Finally 3,
4 and 5 show the overriding with three files (only one at a time).
3 Has global English and special string. 4 Has special string and
local string from frtext.cfg (just like 2). 5 overrides both with
special strings. Note that the language override for French makes 4
output "BlahBlah uno" instead of "How are you?" as in the first line.
Unfortunately this is the only method I can think of that preserves
the language strings of Allegro and allows using get_config_text()
with game provided files. Allegro was initially designed for
mono user mono task OSes where dynamic linking wasn't possible, and
thus a game update meant for the programmer to repackage again all
new Allegro strings in the language.dat file.
I am addressing this with the attached documentation update to both
installation instructions and the programmer manual. Feel free to
comment on the content of these patches and/or suggest better ways to
deal with this problem. Allegro 4.0 and 4.2 are in feature freeze, so
no library side change can be made unless it doesn't break the ABI.
Finally, as personal opinion, I wouldn't care too much about being
"correct" and would go with the environment hack. Even though
language.dat contains Allegro text strings, these will mostly show
up when something goes really wrong (if the programmer has cared
to show them), and they are quite criptic for non developers.
Attachment:
allegro_i18n_test.tar.gz
Description: Binary data
Attachment:
support_files.diff.gz
Description: Binary data