a french beginner
Sébastian
: "is a authoring system avaible in french ?"
Or maybe games can be writed entierly on french... I just begin to try
it with ALAN system but some strings like "You can't do that" are
directly include on the compiler's file (named alan.exe). Therefore,
without the source, the translation seems partial.
Thank you for your attention...
A french guy who feel him very alone around the world of IF
Alex Watson
ISO-8859-1?Q?S=E9bastian?=, posted this to rec.arts.int-fiction:
> I'd just start to discover the IF's world and one question comes to me
> : "is a authoring system avaible in french ?"
> Or maybe games can be writed entierly on french... I just begin to try
> it with ALAN system but some strings like "You can't do that" are
> directly include on the compiler's file (named alan.exe). Therefore,
> without the source, the translation seems partial.
I believe there are French library files for Inform, and there is also an
Inform Translator's Manual that could help you out with writing one if
there isn't one.
--
Alex Watson
http://www.watson1999-69.freeserve.co.uk/froup/
Replies to me[AT]watson1999-69.freeserve.co.uk
"Verbosity leads to unclear, inarticulate things." - Quayle.
Jonathan Rosebaugh
You can program in many languages, including French, with Inform. The
DM4 (particularly Chapter 5 (starting on page 243), will be helpful,
as will
http://www.ifarchive.org/if-archive/infocom/compilers/inform6/library/contributions/french.zip
The DM4 can be obtained at http://www.ifarchive.org/if-archive/infocom/compilers/inform6/manuals/designers_manual_4.pdf
Enjoy!
(Unfortunatly, I don't know French, so I wouldn't be able to play your
games. I don't know how big of an audience you would have.)
--
Skip - http://www.plover.net/~skip/
-----------------------------------
Materiality: A blessing all its own. Spirit-Demons play in fire
hoping for cremation. In the terror of their immortality they envy dying
men.
- Calvin Miller, The Singer Trilogy
SteveG
(=?ISO-8859-1?Q?S=E9bastian?=) wrote:
>I'd just start to discover the IF's world and one question comes to me
>: "is a authoring system avaible in french ?"
Someone else mentioned the French 'library' for the Inform programming
system already. To see what else there was I did a quick search of
r.a.i-f messages as stored at groups.google.com. I was surprised how
little mention there is of French IF. Besides the Inform French
library at the IF Archive, the only other item that stood out was a
mailing list about French Inform. Its now here
http://groups.yahoo.com/group/Inform_fr
Almost no messages or members. But you might make contact with some
people through it.
>Or maybe games can be writed entierly on french... I just begin to try
>it with ALAN system but some strings like "You can't do that" are
>directly include on the compiler's file (named alan.exe). Therefore,
>without the source, the translation seems partial.
You can translate all the Alan strings using the "messages" command.
So you should be able to translate them into French okay.
>Thank you for your attention...
>A french guy who feel him very alone around the world of IF
-- SteveG
remove _X_ from my address to send me email
Greg Ewing
>
> I just begin to try
> it with ALAN system but some strings like "You can't do that" are
> directly include
Recent versions of ALAN allow all of the
built-in messages to be replaced by using the
MESSAGE statement. (See section 3.5 on page
30 of the Alan 2.8 manual).
That only leaves the built-in parser words
such as "all", "it", etc. There doesn't seem
to be any direct way to replace them, but you
should be able to define synomyms for them.
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
David Kinder
> such as "all", "it", etc. There doesn't seem
> to be any direct way to replace them, but you
> should be able to define synomyms for them.
Doesn't that leave the problem of the grammar in the parser
still being designed for English phrases? As far as I'm
aware, only Inform lets you alter the parser's grammar.
David
Michel Nizette
Sébastian wrote:
> [...] A french guy who feel him very alone around the world of IF
I support you.
Unfortunately, I think there is no real good solution for french-speaking
IF programmers like us. This is due to the fact that parsing french
commands is a much more difficult problem than parsing english commands,
and I think that none of the existing systems tackle this issue
satisfyingly. French is really a very complex language. Just consider the
following examples:
1) correct ways to say "give it to her" in french are "donne-le lui"
(which might also mean "give it to him") or "donne-le à elle" (which is
not as nice as the first form), but never "donne-le à lui", which would
mean "give it to him", nor "donne-le elle", which just means nothing.
Thus, you may put the female pronoun ("lui" or "elle") either before or
after the verb ("donne"), but you must take care of correctly choosing
between "lui" or "elle" depending on the pronoun position. If you make the
wrong choice, you might mean "him" instead of "her". Furthermore, notice
that the "to" = "à" preposition is (and must be) omitted in one case, but
must be written explicitly in the other case. Finally, note the required
hyphen between the verb ("donne") and the "it" = "le" pronoun. A french
language parser would have to know when to discard hyphens and when to
treat a couple of words connected by a hyphen as a single entity.
2) a correct way to say "give this to her" in french is "donne lui ceci",
but never "donne-ceci lui". However, "give it to her" can be translated
into "donne-le lui", but never into "donne lui le".
Hence, the rules for positioning the pronouns "it" = "le" and "this" =
"ceci" are different.
I have chosen very painful examples, but this gives the idea of the
problems a parser would have to tackle: a lot of exceptional cases, word
order reversals, and ambiguities (remember that "lui" means "him"
inambiguously in some cases, and means "either him or her" in other
cases). And although my examples only focus on pronouns, analogous
problems hold for prepositions and articles, so that disallowing the use
of pronouns wouldn't be a solution.
Michel Nizette,
A belgian guy who feels very alone around the world of IF, too.
P.S. The best solution I have found is to try to write IF in english as
best as I can. And it's not easy. (I'm a newbie.)
Ross Presser
>
>Sébastian wrote:
>
>> [...] A french guy who feel him very alone around the world of IF
>
>I support you.
>
>Unfortunately, I think there is no real good solution for
>french-speaking IF programmers like us. This is due to the fact that
>parsing french commands is a much more difficult problem than
>parsing english commands, and I think that none of the existing
>systems tackle this issue satisfyingly. French is really a very
>complex language. Just consider the following examples:
>
[snip pronoun examples]
Disclaimer: I speak no French.
I don't entirely agree that the examples you've given make parsing
impossible. A parser needs to accept all valid sentences, but it
causes no harm to accept sentences a human would never write.
--
Ross Presser * ross_p...@imtek.com
"A free-range shoggoth is a happy shoggoth, and a happy shoggoth is
generally less inclined to eat all of you at once." - Tim Morgan
Mike Roberts
> Unfortunately, I think there is no real good solution for french-speaking
> IF programmers like us. This is due to the fact that parsing french
> commands is a much more difficult problem than parsing english commands,
> and I think that none of the existing systems tackle this issue
> satisfyingly. French is really a very complex language. Just consider the
> following examples:
Just a quick obligatory vaporware plug: this is exactly the problem that
the tads 3 parser is designed to solve. Every element of a grammar is
parameterized in declarative form, so you're not locked in to an English
speaker's idea of how noun phrases, verb structures, or pronouns work. This
doesn't reduce the problem to a trivial exercise, since someone has to
rigorously describe the language's grammar, but that rigorous description is
practically all you have to create to build a language-specific parser.
If you can make do with sketchy documentation, the "early adopter" release
is already on gmd for experimentation.
--Mike
mjr underscore at hotmail dot com
Michel Nizette
Ross Presser wrote:
> I don't entirely agree that the examples you've given make parsing
> impossible. A parser needs to accept all valid sentences, but it
> causes no harm to accept sentences a human would never write.
That's true. My examples were meant to show how intricate the french
grammar could be (and, in that spirit, I had taken particularly painful
examples just for the fun of it :-) ), but I admit they don't actually
reveal the most difficult problems to tackle. Also, my examples were
two-pronoun examples, which even english parsers do not accept.
In my opinion, the most challenging difficulties have to do with the fact
that, in french, many words are ambiguous, in the sense that the same
word can either be a preposition or an article, for instance. Just
consider the following example: in french, "parler au propriétaire du
chien" could mean "speak to the owner of the dog", in which case the word
"du" plays the role of the english word "of", which is used here to form
a composite noun phrase. On the other hand, the very same french sentence
could as well mean "tell the owner about the dog", in which case the word
"du" is the preposition "about", used to introduce an indirect object.
Now, as if it weren't complicated enough, the french sentence "donner au
propriétaire du fromage" means "give some cheese to the owner", in which
case the word "du" is an article meaning "some".
I do not mean that these ambiguities are impossible to resolve, but I
think that it is a very nontrivial task. Anyway, you cannot just take an
english parser and substitute french words for the english ones. Instead,
you'll have to hack both the parsing system and the standard libraries
heavily. Which means that, at the time being at least, a french-speaking
programmer cannot use the standard IF-programming systems as they are
without worrying about parsing details--which is just what IF-programming
systems are made for.
Michel Nizette
I'm sorry if I offended you. I was very happy about this indeed when I first
heard about Tads 3. This is really a step towards the internationalization of
parsing systems, which, in my opinion, could bring a nonnegligible new audience
to the IF community. But, as you are saying, somebody still has to describe the
grammar (and write custom standard libraries). As a consequence, I don't think I
am wrong when I say that (at the time being at least) there exists no good
solution for french-speaking IF programmers--which does not mean that there
isn't any important progress in that direction.
Michel Nizette.
Marie-Line Chabanol
|> >[snip]
|> > If you can make do with sketchy documentation, the "early adopter" release
|> > is already on gmd for experimentation.
|> >
|> > --Mike
|> > mjr underscore at hotmail dot com
|>
|> I'm sorry if I offended you. I was very happy about this indeed when I first
|> heard about Tads 3. This is really a step towards the internationalization of
|> parsing systems, which, in my opinion, could bring a nonnegligible new audience
|> to the IF community. But, as you are saying, somebody still has to describe the
|> grammar (and write custom standard libraries). As a consequence, I don't think I
|> am wrong when I say that (at the time being at least) there exists no good
|> solution for french-speaking IF programmers--which does not mean that there
|> isn't any important progress in that direction.
|>
|> Michel Nizette.
|>
What about aventure.z5 and french.h ? I have not yet played the first,
nor used the second, but their existence made me optimistic regarding
the existence of french IF. Would TADS be actually simpler to adapt
than Inform ?
Marie-Line
Michel Nizette
> What about aventure.z5 and french.h ? I have not yet played the first,
> nor used the second, but their existence made me optimistic regarding
> the existence of french IF.
Well, I didn't know about french.h before you mentioned it. The Inform home page
mentions the existence of spanish, german, and italian translations, but says nothing
about the french one, so that I thought none existed so far. I found french.h
well-hidden in the directory tree of the IF archive. So, there actually IS a solution
for french-speaking programmers--my mistake.
> Would TADS be actually simpler to adapt
> than Inform ?
>
> Marie-Line
Frankly, I don't know very much of Inform (as I said, I'm a newbie), because I was much
more attracted by the more modern approach of HTML-Tads. Consequently, I don't know how
good Inform is in adapting to foreign languages (and, in particular, how good french.h
is). But I'm pretty sure that, in order to be really efficient in interpreting french
input, a parser must allow for very flexible grammar definitions. A formal grammar
definition approach similar to Tads 3's looks to me like it could provide the necessary
and sufficient flexibility.
Michel.
Mike Roberts
> > Just a quick obligatory vaporware plug: this is exactly the problem
that
> > the tads 3 parser is designed to solve.
first
> heard about Tads 3.
There was certainly no offense taken at all - I just didn't know if you were
aware of the way the tads 3 parser works (er, will eventually work...).
> But, as you are saying, somebody still has to describe the
> grammar (and write custom standard libraries). As a consequence,
> I don't think I am wrong when I say that (at the time being at least)
> there exists no good solution for french-speaking IF programmers.
I think you're quite right. I offer as encouragement, though, that the
English grammar rules have turned out to be one of the easier parts of the
new library to build. It should be possible to replace just the grammar
rules (and messages) without having to reimplement the rest of the library,
too. Creating a grammar is far from trivial, certainly, but I think it'll
be a lot less work than customizing any of the existing parsers.
Michel Nizette
> > But, as you are saying, somebody still has to describe the
> > grammar (and write custom standard libraries). As a consequence,
> > I don't think I am wrong when I say that (at the time being at least)
> > there exists no good solution for french-speaking IF programmers.
>
> I think you're quite right. I offer as encouragement, though, that the
> English grammar rules have turned out to be one of the easier parts of the
> new library to build. It should be possible to replace just the grammar
> rules (and messages) without having to reimplement the rest of the library,
> too. [SNIP]
I still believe that, in addition to defining the grammar, the parser and
library code still needs to be hacked a bit. For example, in french, the gender
of a noun is a property of the noun itself rather than of the object it
represents. That's because there exist synonym nouns that are of different
genders. For instance, the english noun 'curtain' may be translated either as
the french noun 'rideau', which is male, or as the french noun 'tenture', which
is female.
As a consequence, if you were to implement a curtain in a french-speaking game,
you would probably define both a maleNoun property and a femaleNoun property,
which would be set respectively to the strings 'rideau' and 'tenture'. This is
necessary so that the parser knows which kind of pronoun (male or female) is
used to refer to the curtain object, depending on which noun the player entered
last.
In constrast, in english, you need a noun property of only one kind, which you
would set to 'curtain'. Because the gender is a property of the curtain object
rather than of the noun 'curtain', the parser knows which pronoun to use for
later reference, since it does not depend on which noun has been used last.
Because the models for defining nouns in english and in french are different, I
think that the parser and library codes must be somewhat modified so as to
reflect model changes. However, I do admit that the work that comprises the
grammar definition and library code modification might be far less painful than
trying to fit the french language to an inadequate grammar model.
Michel Nizette.
Mike Roberts
> [on translating a tads 3 parser grammar from English to French]
> I still believe that, in addition to defining the grammar, the parser and
> library code still needs to be hacked a bit.
Hacked in the sense of writing code, yes; hacked in the sense of working
around English-based assumptions with cumbersome patches and tweaks, I hope
not - let me explain...
> For example, in french, the gender of a noun is a property of the noun
itself
> rather than of the object it represents. That's because there exist
synonym
> nouns that are of different genders.
This would be handled as part of what I call the "noun phrase resolution"
process, where the parser determines the game object to which a noun phrase
refers.
The generic (i.e., language-independent) part of the parser doesn't define
noun phrases at all, leaving these to the language-specific part. This
seems the most translation-friendly design because of the wide variability
in the ways different languages encode structural information into noun
phrases; declined languages, for example, would have to define several types
of noun phrases for the different declensions that can appear in commands,
and gendered languages such as French would have to define noun phrase rules
to distinguish gender, presumably from articles and preposition-article
contractions.
The generic parser has some basic classes for common noun phrases -
definite, indefinite, counted, plural - but each language (English included)
must extend these basic classes for language-specific constructs, and must
supply the actual syntax to be parsed.
So, you're quite right that defining a tads 3 grammar isn't going to be
simply a matter of plugging in a bunch of new syntax templates. The nice
thing about the new parser mechanism, though, is that syntax rules and the
semantic interpretation code for those rules are defined together, so when
you add a grammar rule that encodes a gendered noun phrase, you can add
right along with it the code that applies the gender information in
resolving the phrase. And what I hope turns out to be nice about the
library is that you won't be modifying an English parser, but entirely
throwing out just the parts of the parser that make it English-specific and
substituting French-specific equivalents.
To put this in concrete terms, the English parser has a module called
us_eng.t that encodes all of the rules for English (more specifically, as
spoken in the US). To create a French version of the library, you'd remove
this and replace it with something like french.t with a whole new set of
rules for French.
> As a consequence, if you were to implement a curtain in a french-speaking
game,
> you would probably define both a maleNoun property and a femaleNoun
property,
> which would be set respectively to the strings 'rideau' and 'tenture'.
This is
> necessary so that the parser knows which kind of pronoun (male or female)
is
> used to refer to the curtain object, depending on which noun the player
entered
> last.
This is probably just the way I'd suggest handling it. This, too, is part
of the language-specific part of the library - the generic library doesn't
even have noun or adjective properties for just this reason. The
English-specific part is where the noun and adjective properties are
defined, and a French-specific version would probably instead define, as you
say, gendered versions.
> Because the models for defining nouns in english and in french are
different, I
> think that the parser and library codes must be somewhat modified so as to
> reflect model changes.
I agree. The only thing I'd add, and really the whole point of this note,
is that a translated version of the library *extends* rather than modifies
the library - or perhaps a better way to put it is that a translation
completes the library, since the generic framework has holes in it for the
things that are different in every language.
It might sound like this approach simply pushes the work of building an
entire parser onto each translator, given how little one finds in common
among all of the world's languages, but I don't think that'll be the case.
A lot of the hard work is in what a linguist might call the "deep
structure" - the semantic content - and much of this part is in the generic
parser because it's aloof from the details of syntax.
I'm sure that my first many attempts will fall miserably short of this grand
vision of pluggable parsers with perfectly minimized language-specific
modules and a perfectly generalized language-independent core, but perhaps
some brave translators will grapple with the early versions and help me
understand the deficiencies, and in time we can come up with something
pretty decent. At any rate, I like the theory; we'll see how it actually
turns out in practice.
--Mike
Greg Ewing
very much -- it doesn't really matter if the parser
accepts sentences which don't have all the genders
exactly right.
But it will affect the algorithms needed to *generate*
text. E.g. when printing a list of object names, the
library will need to know what gender of article to
put in front of each name.
So language customisation is going to involve a lot
more than just the parser.
Michel Nizette
> I don't think that gender issues will affect the parser
> very much -- it doesn't really matter if the parser
> accepts sentences which don't have all the genders
> exactly right.
> [SNIP]
I don't share your opinion about this. Let's consider the case of a
french parser that knows about character genders (like an english one),
but that ignores noun genders. Just consider the following twisted
example. (I like twisted examples :-) ). I provide english translations
inside brackets.
--------
>interroge Marie à propos du château [ask Mary about castle]
"Comment allons-nous pénétrer dans ce château ? demandez-vous. ["How are
we going to enter that castle?" you ask.]
-- Tu pourrais assommer la sentinelle, répond Marie, c'est un petit
homme faible." ["You could knock the sentry out", Mary replies, "he's a
weak little man."]
>regarde sentinelle [look at sentry]
La sentinelle ne paraît pas très costaude. [The sentry does not look
very strong.]
>attaque-la [attack him]
Vous frappez Marie sans raison. Elle tombe sur le sol, évanouïe. [You
hit Mary without reason. She falls on the ground, unconscious.]
--------
What happened? In french, the noun "sentinelle" ["sentry"] is female.
So, the player naturally used the female pronoun "la" to refer to him,
although he's a man. However, the parser ignored the fact that
"sentinelle" is a female noun. All it was aware of is that the sentry is
a male character and that Mary is a female character, hence it assumed
that the female pronoun "la" was used to refer to the female character
who was mentionned last--Mary.
Michel Nizette.
Magnus Olsson
>very strong.]
>
>>attaque-la [attack him]
>
>hit Mary without reason. She falls on the ground, unconscious.]
>
>--------
>
>What happened? In french, the noun "sentinelle" ["sentry"] is female.
>So, the player naturally used the female pronoun "la" to refer to him,
>although he's a man. However, the parser ignored the fact that
>"sentinelle" is a female noun. All it was aware of is that the sentry is
>a male character and that Mary is a female character, hence it assumed
>that the female pronoun "la" was used to refer to the female character
>who was mentionned last--Mary.
The Inform parser has a similar problem in English, when the same
object can have both plural and singular nouns. For example
object panties
with
name 'panties' 'underwear'
has
plural
;
If the player refers to this as "underwear", or has seen the game refer to
it as such, she will expect to be able to refer to it as "it" - but the
plural flag is set, so the game will not realize that.
Apologies for the slightly off-colour example. A more common case would
be
object apple_bag
with
name 'bag' 'of' 'apples'
;
which the player can refer to as either "apples" (plural) or "bag"
(singular) - however, here it can be argued that the bag and the
apples really are different objects (but what about a gaggle of geese
in that case?).
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Greg Ewing
>
> >attaque-la [attack him]
>
> Vous frappez Marie sans raison.
Hmmm. This would seem to be ambiguous even when all the
rules of gender are taken into account. Resolving it would
require some deeper knowledge to be built into the game
(such as the fact that you're more likely to want to attack
enemies than friends). So I don't think you can blame this
one on the parser not knowing enough about genders.
On the contrary, it looks like it would be better for the
parser to simply treat all pronouns as meaning "he, she
or it" and ask the player to clarify where necessary.
David Librik
>It might sound like this approach simply pushes the work of building an
>entire parser onto each translator, given how little one finds in common
>among all of the world's languages, but I don't think that'll be the case.
>A lot of the hard work is in what a linguist might call the "deep
>structure" - the semantic content - and much of this part is in the generic
>parser because it's aloof from the details of syntax.
>I'm sure that my first many attempts will fall miserably short of this grand
>vision of pluggable parsers with perfectly minimized language-specific
>modules and a perfectly generalized language-independent core, but perhaps
>some brave translators will grapple with the early versions and help me
>understand the deficiencies, and in time we can come up with something
>pretty decent. At any rate, I like the theory; we'll see how it actually
>turns out in practice.
What you're trying to solve is the same problem that most of modern
Linguistics is working on. Is this your own design, or have you looked
at any developed "theories of grammar"? It's not an easy problem, as
you probably have spotted. Pronoun reference tracking is especially
tough.
I think what you'll find is that, no matter what universal principles
you come up with, someone will be able to find a language phenomenon
that your design can't handle. Then you will get a free membership in
the Linguistic Society of America's "Battlescarred Veterans Of Syntax"
club. :-)
I think the best thing for this part of TADS 3 is to get lots of speakers
of non-English languages to try their hands at automating their languages'
grammars. That should flush out the problems nicely...
- David Librik
Michel Nizette
> [SNIP] Hmmm. This would seem to be ambiguous even when all the
> rules of gender are taken into account.
Why? In the example I have given, the player referred successively to
(i) Mary (a female noun), (ii) the castle (a male noun in french), and
(iii) the sentry (a female noun in french). Therefore, a female pronoun
must refer to the same object as the female noun which was entered last:
the sentry. I do not see any ambiguity here. I do admit, however, that
the fact that a female noun may refer to a male character in french is
pretty confusing, and completely illogical. The french language contains
lots of such illogical constructs, to which french-speaking people are
used. But illogical does not mean ambiguous.
And, implementing the sentry as being a female character would not be a
solution either, because the player must be able to refer to him as the
"weak little man", which implies the subsequent use of a male pronoun.
> Resolving it would
> require some deeper knowledge to be built into the game
> (such as the fact that you're more likely to want to attack
> enemies than friends). So I don't think you can blame this
> one on the parser not knowing enough about genders.
I don't think that just making built-in assumptions about which
characters the player might be more likely to attack would be a true
solution to the problem. Indeed, the problem is a syntactical one, not a
semantical one. Let me explain: the parser wrongly assumed that the
player meant to punch Mary instead of the sentry. This was wrong because
the sentry was the last female noun that was referred to. NOT because
the sentry is a foe and Mary is a friend. Furthermore, we may imagine
another situation, where Mary is a spy playing a double role, in which
case the player might have a good reason to attack Mary instead of the
sentry, as part of his strategy. Then there is no semantical reason to
make assumptions about whom the player might attack. But even in that
case, it is wrong to assume that the female pronoun refers to Mary if
another female noun has been mentioned more recently.
> On the contrary, it looks like it would be better for the
> parser to simply treat all pronouns as meaning "he, she
> or it" and ask the player to clarify where necessary.
Would that be acceptable in english? I don't think so. Imagine the
following.
There are a nurse and a little boy here.
>give him the box of candies
To whom do you want to give the box of candies, the nurse or the little
boy?
Isn't that frustrating? I think that even the more radical solution of
disallowing the use of pronouns would be better.
Michel Nizette.