[Inform] Swedish.h
Fredrik Ramsberg
I've written a Swedish.h which is now ready for an alpha release. I'd like
to ask for one or a few individuals willing to test it. The ideal tester
has good knowledge of Swedish, English and Inform.
I'd like to mention a few problems that arise when writing games in
Swedish. They apply for many other languages as well, and as long as they
remain unresolved, Graham's efforts to make Inform translation-friendly
are of quite limited value. If all Inform porters and interpreter
writers hear this call, Inform may actually become useful for writing
games in other languages.
1: Few interpreters accept accented input. When I press "ö" on my keyboard
in WinFrotz (my terp of choice), I get "?" on the screen.
2: The compiler crashes if I use accented characters in dictionary words.
This is due to the fact that it uses signed chars on most platforms. On
the Win32 platform, this is currently being addressed by Kirk Klobe,
but this is most probably a problem on more platforms.
3: By using escape codes, I can get away with writing accented characters in
dictionary words, but they will never be found to match when I type
something in, even if I do use an interpreter that accepts accented
characters in input. This is because I have declared new Zcharacters
to make the accented characters cheaper, but these cheaper codes are
not used when encoding dictionary words. Without cheaper codes, some
words get only 2-3 significant characters in a v5 game.
These problems _can_ be solved. Kevin Bracey has helped me very much in
finding the problems, and I think he now has a fully working compiler
(at least as far as these issues are concerned) and a fully working
interpreter. Unfortunately, I don't have a Risc OS machine, so I can't
use them.
Please mail me if I can be of any help in finding and fixing these problems.
Right now my efforts with Swedish.h feel a bit wasted, so I'm eager to get
a working compiler and terp.
/Fredrik
Matthew Russotto
Fredrik Ramsberg <f...@mail.com> wrote:
>
>These problems _can_ be solved. Kevin Bracey has helped me very much in
>finding the problems, and I think he now has a fully working compiler
>(at least as far as these issues are concerned) and a fully working
>interpreter. Unfortunately, I don't have a Risc OS machine, so I can't
>use them.
You probably don't have a Mac either, so a new revision of Zip
Infinity wouldn't help.
The compiler fixes should be pretty generic, I would think.
--
Matthew T. Russotto mrus...@speakeasy.net
=====
Dmitry is free, but the DMCA survives. DMCA delenda est!
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Fredrik Ramsberg
> In article <ab01df60.01121...@posting.google.com>,
> Fredrik Ramsberg <f...@mail.com> wrote:
> >
> >These problems _can_ be solved. Kevin Bracey has helped me very much in
> >finding the problems, and I think he now has a fully working compiler
> >(at least as far as these issues are concerned) and a fully working
> >interpreter. Unfortunately, I don't have a Risc OS machine, so I can't
> >use them.
>
> You probably don't have a Mac either, so a new revision of Zip
> Infinity wouldn't help.
But it would! Even though I personally have no more Macs than I have
Acorns, every interpreter that gets updated is very important. If there
are no Mac terps that support accented characters, the interest in writing
games that need accented characters is smaller. So, yes it helps not only
me, but a lot of people who write in languages that need accented characters.
I can get on with the testing of Swedish.h now, by running all my source
code through a script that turns "å" into "aa", "ä" into "ae" and "ö" into
"oe". I've seen it work properly on Zip2000, so I know it will work as it
should one day. However, as long as no other terps support it, I can't
expect much interest in games in Swedish. Imagine me telling you that one
third of your vowels can't be typed into any games, they have to be
replaced by combinations of other vowels. Instead of "examine the
flask" you'll have to type "ouxoiminou thou floisk". That's _exactly_ how
bad the situation is. Would you be keen on playing IF games?
Also remember that if your terp is the only one on your platform that
has proper support for accented characters, it will be the only terp
used by people playing games written in languages that require accented
characters.
Add up the people who have either Spanish, Portuguese, French or German
as their mother tongue, and you end up with a neat crowd of more than
700 000 000 people (Yes I wanted you to count the zeroes). Aren't they,
as a potential audience, worth the effort of at least implementing the
Latin-n charsets in both input and output?
> The compiler fixes should be pretty generic, I would think.
They are. These problems have already been solved, and the solutions
are available at the Inform Patch Page. The main Inform source is just
lagging behind. This means that porters need to apply patches and
re-release the same compiler version but with a new build number or
something (probably keeping the old version available for reference).
This has now been done for the Win32 port, and the new version should be
available at if-archive soon.
/Fredrik
Matthew Russotto
Fredrik Ramsberg <f...@mail.com> wrote:
>russ...@wanda.pond.com (Matthew Russotto) wrote in message news:<u240dma...@corp.supernews.com>...
>>
>> Infinity wouldn't help.
>
>
>Add up the people who have either Spanish, Portuguese, French or German
>as their mother tongue, and you end up with a neat crowd of more than
>700 000 000 people (Yes I wanted you to count the zeroes). Aren't they,
>as a potential audience, worth the effort of at least implementing the
>Latin-n charsets in both input and output?
Look at it from the BPFH (like a Bastard Operator from Hell, but
programming rather than operating) perspective. You see 700,000,000
users. I see 700,000,000 people sending me bug reports, quite a few
of them in some language I don't understand, about things I have
trouble testing because I don't know the language.
OK, I'm just being grumpy because proper support is difficult (It would
be easier on Windows, believe it or not... at least Windows has a
simple native<->Unicode<->any other script call. The Mac, exclusive
of Cocoa, does not appear to)
Kevin Bracey
news:u24h07e...@corp.supernews.com...
> OK, I'm just being grumpy because proper support is difficult (It would
> be easier on Windows, believe it or not... at least Windows has a
> simple native<->Unicode<->any other script call. The Mac, exclusive
> of Cocoa, does not appear to)
He's not asking you for Unicode though. Or at least not yet :) He's just
asking for the level of accented character support that was originally
specified in Standard 0.2 - ie the fixed set of accented letters plucked
from the Latin-1 repertoire.
I sympathise with the Unicode point though. When I did Zip 2000, RISC OS had
no Unicode support either. I've only just put in its first use of a Unicode
system call yesterday - up until then it relied totally on its own mapping
tables.
Kevin
-----
Matthew Russotto
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>"Matthew Russotto" <russ...@wanda.pond.com> wrote in message
>news:u24h07e...@corp.supernews.com...
>> OK, I'm just being grumpy because proper support is difficult (It would
>> be easier on Windows, believe it or not... at least Windows has a
>> simple native<->Unicode<->any other script call. The Mac, exclusive
>> of Cocoa, does not appear to)
>
>He's not asking you for Unicode though. Or at least not yet :) He's just
>asking for the level of accented character support that was originally
>specified in Standard 0.2 - ie the fixed set of accented letters plucked
>from the Latin-1 repertoire.
That already works, as much as the Mac can support it without going
to weird crap like Worldscript. (you can't type an eth or a thorn on
a US keyboard, for instance)
Daniel Barkalow
> I can get on with the testing of Swedish.h now, by running all my source
> code through a script that turns "å" into "aa", "ä" into "ae" and "ö" into
> "oe". I've seen it work properly on Zip2000, so I know it will work as it
> should one day. However, as long as no other terps support it, I can't
> expect much interest in games in Swedish. Imagine me telling you that one
> third of your vowels can't be typed into any games, they have to be
> replaced by combinations of other vowels. Instead of "examine the
> flask" you'll have to type "ouxoiminou thou floisk". That's _exactly_ how
> bad the situation is. Would you be keen on playing IF games?
Can you use only unaccented characters in the input? "iximini thi
flisk" isn't too bad, if you're only typing it and not reading it. Of
course, the accents and such in the text are more important, but that
seems to be more of a solved problem.
-Iabervon
*This .sig unintentionally changed*
Fredrik Ramsberg
> On 20 Dec 2001, Fredrik Ramsberg wrote:
>
> > I can get on with the testing of Swedish.h now, by running all my source
> ? into
> > "oe". I've seen it work properly on Zip2000, so I know it will work as it
> > should one day. However, as long as no other terps support it, I can't
> > expect much interest in games in Swedish. Imagine me telling you that one
> > third of your vowels can't be typed into any games, they have to be
> > replaced by combinations of other vowels. Instead of "examine the
> > bad the situation is. Would you be keen on playing IF games?
>
> Can you use only unaccented characters in the input? "iximini thi
> flisk" isn't too bad, if you're only typing it and not reading it. Of
> course, the accents and such in the text are more important, but that
> seems to be more of a solved problem.
Yes, printing is more of a solved problem.
I certainly wouldn't like to type "iximini thi flisk" when I mean "examine
the flask". Another problem is that in Swedish, unlike German and French,
the same character with different accents are considered as completely
different characters. For instance "ara" is a kind of parrot, "åra" is an
oar, while "ära" means honor. It feels quite unnatural to type parrot when
I mean oar.
Please just try a bit of empathy for a second. Would you _really_ accept
even "iximini thi flisk" in the long run, or would it diminish your interest
in IF? If we get the Latin scripts covered, we also cover quite a bunch of
new languages. A more complete Unicode support may not seem as difficult
after that either.
/Fredrik
Fredrik Ramsberg
> In article <9vtiqd$831$1...@newsg2.svr.pol.co.uk>,
> Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
> >"Matthew Russotto" <russ...@wanda.pond.com> wrote in message
> >news:u24h07e...@corp.supernews.com...
> >> OK, I'm just being grumpy because proper support is difficult (It would
> >> be easier on Windows, believe it or not... at least Windows has a
> >> simple native<->Unicode<->any other script call. The Mac, exclusive
> >> of Cocoa, does not appear to)
> >
> >He's not asking you for Unicode though. Or at least not yet :) He's just
> >asking for the level of accented character support that was originally
> >specified in Standard 0.2 - ie the fixed set of accented letters plucked
> >from the Latin-1 repertoire.
>
> That already works, as much as the Mac can support it without going
> to weird crap like Worldscript. (you can't type an eth or a thorn on
> a US keyboard, for instance)
Does it support all characters in this set as long as the user has a keyboard
that can type them? In that case, that's great! If, on the other hand, you
mean that there's no point in supporting some of the characters, since they
can't be typed on a US keyboard anyway, that's not so great. Some people have
non-US keyboards.
/Fredrik
Muffy St. Bernard
Myself, if I had to remind myself to (for example) use the letters
"ao" every time I wanted to type the letter "o" -- and do the same for
two other extremely common vowels -- nao daoubt I waould naot have taoao
much fun playing.
Too bad...it seems to me that playing Swedish IF would be a great way
to learn the language.
Muffy.
chy...@ludens.elte.hu
All the Hungarian IF I've seen has this same problem (Hungarian makes 14
vowels out of the basic 5 through liberal use of various accents), and
they solve it with the "iximini thi flisk" method. It is _deifinitely_
less bothersome than the "ouxoiminou thou floisk" route, and one gets
used to it quite quickly.
> Muffy.
Chyron
--
"Beware of he who would deny you access to information, for in his
heart he dreams himself your master." -- Commissioner Pravin Lal
"People who think they have a right not to be offended are trouble."
-- Alsee
Matthew Russotto
>>
>> to weird crap like Worldscript. (you can't type an eth or a thorn on
>> a US keyboard, for instance)
>
>Does it support all characters in this set as long as the user has a keyboard
>that can type them?
No. I have no idea what a non-US keyboard would type in those cases,
so I can't do the translation.
Kevin Bracey
> In article <ab01df60.01122...@posting.google.com>,
> Fredrik Ramsberg <f...@mail.com> wrote:
> >
> >Does it support all characters in this set as long as the user has a
keyboard
> >that can type them?
>
> No. I have no idea what a non-US keyboard would type in those cases,
> so I can't do the translation.
Is the Mac API really that hopeless? Surely you just receive Key Pressed
events with the appropriate character code? If you, as a first-pass
implementation, assume that all the codes you get are in the standard
MacRoman alphabet, then there shouldn't be a problem. Do you actually need
to know anything about the keyboard layout?
Doesn't the Mac also come with some sort of on-screen keyboard utility that
lets you access funny characters?
Kevin
-----
Kevin Bracey
> All the Hungarian IF I've seen has this same problem (Hungarian makes 14
> vowels out of the basic 5 through liberal use of various accents), and
> they solve it with the "iximini thi flisk" method. It is _deifinitely_
> less bothersome than the "ouxoiminou thou floisk" route, and one gets
> used to it quite quickly.
But isn't that pretty tragic? We have IF systems fully capable of handling
Hungarian properly, but you find yourself unable to use them due to the vast
majority of interpreter authors being American and not making the extra bit
of effort to implement the systems properly.
Kevin
-----
Andrew Plotkin
This is self-contradictory. If the interpreter doesn't handle it, the
IF system isn't fully capable of it. And you're also begging the
question of which parts of the task are hard and which are only "a
bit of effort".
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Matthew Russotto
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>"Matthew Russotto" <russ...@wanda.pond.com> wrote in message
>news:u26m4va...@corp.supernews.com...
>> In article <ab01df60.01122...@posting.google.com>,
>> Fredrik Ramsberg <f...@mail.com> wrote:
>> >
>> >Does it support all characters in this set as long as the user has a
>keyboard
>> >that can type them?
>>
>> No. I have no idea what a non-US keyboard would type in those cases,
>> so I can't do the translation.
>
>Is the Mac API really that hopeless? Surely you just receive Key Pressed
>events with the appropriate character code? If you, as a first-pass
>implementation, assume that all the codes you get are in the standard
>MacRoman alphabet, then there shouldn't be a problem. Do you actually need
>to know anything about the keyboard layout?
MacRoman doesn't include all the codes. That is what I do assume,
though.
As for the API... yes, it is all that hopeless. The original was developed
pre-Unicode (and pre-Latin-1) and shows it. The Unicode services were
apparently developed by committee.
Kevin Bracey
> MacRoman doesn't include all the codes. That is what I do assume,
> though.
It contains most of the Latin-1 repertoire though, and it's certainly got
enough for Swedish. So from what you've said, Swedish stuff should work
already.
I'm not quite sure why we're sitting around talking about it though. Are
there any Mac users here willing to try out test files from Fredrik on Zip
Infinity?
Kevin
-----
Kevin Bracey
news:a001gp$4io$1...@news.panix.com...
>
> This is self-contradictory. If the interpreter doesn't handle it, the
> IF system isn't fully capable of it.
The compiler can handle it, the manual explains how it works, and some
interpreters work just fine. Unfortunately, many don't. If you're going to
apply that sort of logic, then I'll say that Glulx isn't fully capable of
graphics.
> And you're also begging the
> question of which parts of the task are hard and which are only "a
> bit of effort".
Handling any individual alphabet, such as Latin-1, is pretty trivial.
Handling more is incremental effort. The next stage is to move to general
purpose Unicode support, which is an extra chunk of work, but pretty much
wraps up all language issues.
English language programmers are generally a lazy bunch and feel that
supporting Latin-1 rather than just ASCII is as much as they can be expected
to do, alas.
Kevin
-----
Andrew Plotkin
> "Andrew Plotkin" <erky...@eblong.com> wrote in message
> news:a001gp$4io$1...@news.panix.com...
>>
>> This is self-contradictory. If the interpreter doesn't handle it, the
>> IF system isn't fully capable of it.
> The compiler can handle it, the manual explains how it works, and some
> interpreters work just fine. Unfortunately, many don't.
That's what I said.
> If you're going to
> apply that sort of logic, then I'll say that Glulx isn't fully capable of
> graphics.
I'm not playing word games. Nobody claims that Glulx, as a development
system, is "fully capable of graphics". Nor am I using that phrase to
apply moral pressure on terp authors to add graphics support.
Matthew Russotto
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>
>Handling any individual alphabet, such as Latin-1, is pretty trivial.
>Handling more is incremental effort.
Uh, no. If the OS only supports one alphabet (e.g. MacRoman),
handling any characters outside that alphabet becomes more than an
incremental effort.
Daniel Barkalow
> Daniel Barkalow <iabe...@iabervon.org> wrote in message news:<Pine.LNX.4.21.01122...@iabervon.org>...
> > On 20 Dec 2001, Fredrik Ramsberg wrote:
> >
> > > I can get on with the testing of Swedish.h now, by running all my source
> > > code through a script that turns "? into "aa", "? into "ae" and "
> > ? into
> > > "oe". I've seen it work properly on Zip2000, so I know it will work as it
> > > should one day. However, as long as no other terps support it, I can't
> > > expect much interest in games in Swedish. Imagine me telling you that one
> > > third of your vowels can't be typed into any games, they have to be
> > > replaced by combinations of other vowels. Instead of "examine the
> > > flask" you'll have to type "ouxoiminou thou floisk". That's exactly how
> > > bad the situation is. Would you be keen on playing IF games?
> >
> > Can you use only unaccented characters in the input? "iximini thi
> > flisk" isn't too bad, if you're only typing it and not reading it. Of
> > course, the accents and such in the text are more important, but that
> > seems to be more of a solved problem.
>
> Yes, printing is more of a solved problem.
>
> I certainly wouldn't like to type "iximini thi flisk" when I mean "examine
> the flask". Another problem is that in Swedish, unlike German and French,
> the same character with different accents are considered as completely
> different characters. For instance "ara" is a kind of parrot, "åra" is an
> oar, while "ära" means honor. It feels quite unnatural to type parrot when
> I mean oar.
If the game did the right thing, I wouldn't mind typing "drip" when I
meant "drop".
> Please just try a bit of empathy for a second. Would you _really_ accept
> even "iximini thi flisk" in the long run, or would it diminish your interest
> in IF? If we get the Latin scripts covered, we also cover quite a bunch of
> new languages. A more complete Unicode support may not seem as difficult
> after that either.
I'd certainly like to be able to type "iximini thi flisk" if I'm at a
keyboard that doesn't have other vowels, or using an interpreter that
doesn't support them. So, in order for games to be playable by people who
speak Swedish but don't have the keyboard necessary to accurately type in
it, the game has to recognize the unaccented vowels.
Of course, where the accented vowels are available, they should work; I'd
be confused if a game did not recognize "drop" if I managed to type
it. So, if the OS and hardware support the characters, the interpreter
should, too. But it's really hard to write program features that won't
work on the machine you're using.
Fredrik Ramsberg
> In article <ab01df60.01122...@posting.google.com>,
> Fredrik Ramsberg <f...@mail.com> wrote:
> >russ...@wanda.pond.com (Matthew Russotto) wrote in message news:<u24kjtn...@corp.supernews.com>...
> >>
> >> That already works, as much as the Mac can support it without going
> >> to weird crap like Worldscript. (you can't type an eth or a thorn on
> >> a US keyboard, for instance)
> >
> >Does it support all characters in this set as long as the user has a keyboard
> >that can type them?
>
> No. I have no idea what a non-US keyboard would type in those cases,
> so I can't do the translation.
There is probably someone reading this who has a Mac with a non-US keyboard,
full of accented characters and all. Maybe even someone with experience from
developing internationalised software for Mac is following this discussion.
Could someone please step forward and volunteer to do some tests on the
Zip Infinity, to see what the status is? You can mail me if you like, and
I'll supply you with some test material. I'm under the impression that
Matthew is also interested in this issue, so presumably you can mail him if
you prefer.
/Fredrik
Daniel Barkalow
> The compiler can handle it, the manual explains how it works, and some
> interpreters work just fine. Unfortunately, many don't. If you're going to
> apply that sort of logic, then I'll say that Glulx isn't fully capable of
> graphics.
I have this weird desire to have a text adventure require graphical (or
audio) input.
] TELL BOB {about_house.wav}
Bob is deaf, and does not understand.
] WRITE STORY ON PAPER
Bob can't read, so you'll have to use pictures.
] DRAW {house1.svg} ON PAPER
Fredrik Ramsberg
> Myself, if I had to remind myself to (for example) use the letters
> "ao" every time I wanted to type the letter "o" -- and do the same for
> two other extremely common vowels -- nao daoubt I waould naot have taoao
> much fun playing.
> Too bad...it seems to me that playing Swedish IF would be a great way
> to learn the language.
Indeed. I certainly owe a lot of my knowledge of English to IF. What makes
playing IF better than reading books is that you can't ignore words you
don't understand. If you do, as soon as you get stuck, you will have to go
back and do the job then. Since you _know_ you'll get stuck, you tend to
look up words right away instead. And you have to understand every meaning
of the word, to make sure you got the right one. It means you spend some
time with the dictionaries, but that time never felt wasted to me. And as
you learn the words in a context, it's much easier to remember them than
when you learn 20 new words from a list because it's part of class.
I think playing IF also makes for more active reading, where you
concentrate more on the way everything is written. You have to understand
just how the prepositions work and examine how they are placed to be sure
you understand the situation right.
You also learn to express yourself in speech, but only in imperative
sentences which may get on people's nerves if you practice while
abroad... ;) "Sir, give me the map!"
IF could also be developed especially for the purpose of language training,
with all of the text provided as sampled speech as well. Then you'd get
the hang of the pronounciation at the same time. Actually, that sounds
interesting to try out....
/Fredrik
Petter Sjölund
> I'm not quite sure why we're sitting around talking about it though. Are
> there any Mac users here willing to try out test files from Fredrik on Zip
> Infinity?
>
> Kevin
> -----
>
>
>
I am.
By the way, it's quite straightforward to choose a "foreign" keyboard
layout in Mac OS, in order to type accented characters on an American
keyboard. Open "Character Set" or something similar ("Teckenuppsättning"
in Swedish Mac OS),in Settings. Tick the Swedish layout, and you'll get
a "flag" menu on the status bar. Choose Swedish from there, and study
your new layout with Key Caps.
Zip Infinity does accept Swedish characters as input, MaxZip does not.
/Petter
Kevin Bracey
> In article <a0066h$e0h$1...@news8.svr.pol.co.uk>,
> Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
> >
> >Handling any individual alphabet, such as Latin-1, is pretty trivial.
> >Handling more is incremental effort.
>
> Uh, no. If the OS only supports one alphabet (e.g. MacRoman),
> handling any characters outside that alphabet becomes more than an
> incremental effort.
If that was true, then yes, but then I wouldn't expect any Hungarian people,
say, to own computers that couldn't handle Hungarian at all.
Any Hungarian people with a Mac would have it set up to use Mac Central
European (I think) - and you would use that. It may be that you could only
handle Hungarian on such a system, and not an English one, but it would be
incremental effort to detect the alphabet in use and adapt to it.
Kevin
-----
Kevin Bracey
> Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
> > If you're going to
> > apply that sort of logic, then I'll say that Glulx isn't fully capable
of
> > graphics.
>
> I'm not playing word games. Nobody claims that Glulx, as a development
> system, is "fully capable of graphics". Nor am I using that phrase to
> apply moral pressure on terp authors to add graphics support.
Then we're just talking at cross-purposes, I think. I would certainly claim
that Glulx is "fully capable of graphics", in the sense that the tools to
create graphical content exist, the relevant standards documents clearly
specify the file formats and API that are used, and there is at least one
functioning content viewer. Therefore, it supports graphics.
The capabilities of individual user agents don't have a bearing on it - the
graphical content exists "in potentia" for each user until they get their
hands on a graphical interpreter.
Or at least, that's the way I look at this sort of thing.
Kevin
-----
Matthew Russotto
Petter Sjölund <igna...@mac.com> wrote:
>Zip Infinity does accept Swedish characters as input, MaxZip does not.
Thanks for the info.
D. Jacob Wildstrom
>All the Hungarian IF I've seen has this same problem (Hungarian makes 14
>vowels out of the basic 5 through liberal use of various accents), and
>they solve it with the "iximini thi flisk" method. It is _deifinitely_
>less bothersome than the "ouxoiminou thou floisk" route, and one gets
>used to it quite quickly.
OK, I'm curious, because I have a crude grasp of Hungarian, not really
enough to play a text adventure, but what are some Hungarian text
adventures, and where are they located?
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+
Sean T Barrett
>English language programmers are generally a lazy bunch and feel that
>supporting Latin-1 rather than just ASCII is as much as they can be
>expected to do, alas.
I find it hard to be critical of "lazy programmers" who are
doing their work gratis.
For example, if anyone wants better Latin-1/Unicode support from
WinFrotz (which I seem to be being perceived as the official
maintainer of), they can feel free to program it themselves or
hire a programmer to do the work for them[*]. After Xmas is over
I should be integrating some old fixes and releasing source/binaries
for my current improvements to it, but someone can start before then
as merging shouldn't be problematic.
Sean
[*] The latter is expensive, of course, but then personally,
I value my free time more than you would probably pay any
programmer on contract for this. Hmm, indeed, if anybody wants
to pay me US $100 per hour to work on it, feel free, but since I
don't have any familiarity with the issues on the windows
platform it would take me extra time you'd be paying for,
so I really don't think I'm the ideal person to work on it.
Daniel Dawson
written by Fredrik Ramsberg <f...@mail.com>. It says:
>IF could also be developed especially for the purpose of language training,
>with all of the text provided as sampled speech as well. Then you'd get
>the hang of the pronounciation at the same time. Actually, that sounds
>interesting to try out....
Indeed. I kind of like the sound of that, too. Of course, it would take an
immense amount of space to include a reading of the whole text (but then, I
guess it could be compressed). And one would need to be careful to read every
single fragment of text that is meant for output (and probably some other
things as well), as well as any potential plurals. And of course in other
languages there are hosts of issues with inflection (gender/number/case and
declension in German, for instance). So, if anyone decides to try this, to them
I say, "Good luck".
--
Daniel Dawson
dda...@nospam-altavista.net (remove 'nospam-' to send mail)
Fredrik Ramsberg
Perhaps NovelLib would be helpful -- dividing the screen up in two parts,
where one part should contain unbroken prose generated as output, while
the other part contains input as well as error messages and the like.
If you have the player develop a story rather than solve problems, this
approach could be more manageable. On the other hand, I think it's the
problem solving part of IF that makes it excellent language training.
/Fredrik
Fredrik Ramsberg
> For example, if anyone wants better Latin-1/Unicode support from
> WinFrotz (which I seem to be being perceived as the official
> maintainer of), they can feel free to program it themselves or
> hire a programmer to do the work for them[*]. After Xmas is over
> I should be integrating some old fixes and releasing source/binaries
> for my current improvements to it, but someone can start before then
> as merging shouldn't be problematic.
Personally I think this attitude is just fine. Most people maintaining code
have limited free time to do it in, and I can't tell them how to set their
priorities. However, I do think quite a few IF related programs have too few
people or people with too little time on their hands as maintainers. This
tends to make the projects lag behind.
I wish more people would do like Sean, inviting anyone to write the needed
patch, and offering to merge it with his code (assuming the patch is
properly done of course). If someone with the right profile steps forward,
I'd guess this could be ready for testing by this time tomorrow.
Perhaps more of these projects should be on Source Forge or something
similar, allowing pretty much anyone to work on them?
/Fredrik