Einer der häufig genannten Kritikpunkte an der deutschen Erweiterung für Inform 7 ist das offensichtliche Kauderwelsch, in dem der Quelltext vermeintlich verfasst werden muss.

Dabei lässt sich das ganz einfach unterbinden (es musste einem nur endlich mal einfallen, wie):

A room is usually privately-named.

Jetzt kann man alle Dinge und Räume nennen wie man will, ohne dass der Bezeichner ins Vokabular übernommen wird. Den Rest, also den angezeigten Objektnamen (printed name) und die Synonyme etc., muss man – wie in Inform 6 auch – auf Deutsch angeben.

Ein Beispiel mit englischen Bezeichnern:

Include German by Banbury & Christian Bluemke.

A thing is usually privately-named.

A room is usually privately-named.

Definition: A container is empty if nothing is in it.

When play begins:

   say "So ein Mist! Schon wieder verschlafen.";

   move the player to the bed, without printing a room description.

The bedroom is a room. "Dies ist der am meisten bewohnte Teil des exklusiven Penthouses." The printed name is "Schlafzimmer".

The apple is a male thing carried by the player. The printed name is "Apfel". Understand "Apfel" as the apple.

The red herring is a male thing in bedroom. The printed name is "rot[^] Hering". Understand "rot Hering" and "Hering" as the herring.

A bed is here, fixed in place. The bed is an enterable container. Instead of putting something on the bed, try inserting the noun into the bed. After printing the name of the empty bed: omit contents in listing. The printed name of the bed is "Bett". Understand "Bett" as the bed.

Instead of going nowhere from the bedroom:

   if the noun is inside:

      say "(ins Bett)[command clarification break]";

      try entering the bed.

Sieht etwas besser aus, oder?

Ich habe mal eine Vorab-Testversion der German Version 2 hochgeladen, in der oben beschriebenes Verfahren zur Erstellung von Objekten im Spiel als Standard eingebaut ist. Für diejenigen, die es besser finden, dass der Bezeichner automatisch auch im angezeigten Namen (printed name) und im Vokabular verwendet wird, und dafür einen Sprachmix tolerieren, gibt es Klassen mit deutschen Bezeichnungen – wenn schon Denglisch, dann aber auch volle Power!

Wenn thing und room sich wie gehabt verhalten sollen, z.B. bei einem laufenden Projekt, kann man in seinem Quelltext schreiben:

A room is usually publically-named.```

Interessierte können ja schon mal einen Blick auf die Änderungen der nächsten GerX-Version werfen, bevor ein neuer I7-Build erscheint.

[http://www.pageturner.de/adventure/inform7/Test/German.i7x](http://www.pageturner.de/adventure/inform7/Test/German.i7x)

Die Patch-Extension der Version 1 ist nicht mehr mit der aktuellen Version kompatibel (und auch nicht mehr notwendig). Die integrierte Dokumentation ist noch nicht vollständig umgeschrieben!

**Liste der Änderungen gegenüber Version 1/090621:**

-- Die Klassen (kinds) "thing" und "room" sind nun "privately-named". Das bedeutet, dass der interne Bezeichner nicht ins Vokabular übernommen wird; man kann den Dingen und Räumen also einfach englische Namen geben, was den Quelltext besser aussehen lässt. Der angezeigte Objektname und die Synonyme müssen dann, wie auch schon mit Inform 6, gesondert angegeben werden.

The apple is a male thing. The printed name is "Apfel". Understand "Apfel" as the apple.

-- Die Eigenschaft "article" ist in "special indefinite article"

umbenannt worden, um deutlich zu machen, dass es sich hierbei um eine Sonderform des indefinite article handelt, die ebenfalls nur bei der Ausgabe mit unbestimmtem Artikel herangezogen wird.

-- Neue Check-Rule für putting it on und inserting it into.

>SETZ/LEG DICH AUF SOFA funktionierte nicht richtig. Möglicherweise wird diese Änderung ab dem nächsten Inform-Build überflüssig.

-- Die Plural-Imperativ-Form ("nehmt platz") wird nun richtig erkannt.

-- Korrekturen bei den Verben:

Die gruppierten Präpositionen ("in/auf") vor dem Dativ-Token aufgelöst, um falsche Parser-Nachfragen zu vermeiden.

-- Alle deutschen Me-, Again- und Oops-Wörter werden jetzt verstanden.

-- Bei der Verwendung des special indefinite article "yours" werden Objektnamen mit Adjektiven im Plural nun korrekt ausgegeben ("grüne Tomaten" vs. "deine grünen Tomaten").

-- Fehler im Zusammenhang mit den Textersetzungen "[Ihn]" und "[ihn]" behoben.

Viele Grüße,

Christian

hmpf

Der Standard zum Definieren von Objekten wird nun doch nicht geändert. Das schafft zu viel Durcheinander und außerdem funktioniert der Changing Gender dann nicht mehr.

Falls jemand zufällig eine Möglichkeit entdeckt, die Erzeugung der Two-Pass parse name für ein Objekt zu hacken, bitte melden :-)

http://www.pageturner.de/adventure/inform7/Test/German.i7x

Hier noch mal zusammenfassend ein Nachschlag zum Thema "einsprachige Objektdefinitionen" im Zusammenhang mit dem Changing Gender.

Wenn man Objekte mit englischen Bezeichnern definieren möchte, reicht es, wenn man die Arten "room" und "thing" als "privately-named" definiert. Die deutschen Ein- und Ausgabetexte müssen komplett von Hand nachgeliefert werden.

blue

Jetzt ist Folgendes möglich:

blue

Ein Objekt, das "privately-named" ist, bekommt auf dem I6-Level keine name-Property, was aber für den Changing Gender zwingend notwendig ist, zumindest bei der derzeit verwendeten Mechanik. Diese Objekte parsen sich über eine parse_name property völlig autark.

Ein in I7 definiertes CG-Attribut (hier: weiblich), so wie es bei "publically-named"-Objekten funktioniert, ...

blue

... wird galant ignoriert, "Kiste" jedoch als Synonym verstanden.

Ich meine ja, dass es zu einem sauberen Design gehört, wenn die vom Geschlecht des Objekts abweichenden Synonyme die Pronomen korrekt setzen. Also habe ich darüber nachgedacht, wie man den Changing Gender vielleicht von der name-Property trennen könnte und das Ganze in I7 schön zu benutzen ist -- bin aber zu keinem praktikablen Ergebnis gekommen.

Schön, aber nicht zu realisieren, wäre so etwas:

red

Immerhin kann man die Synonyme und die dazugehörigen Gender-Attribute gefahrlos per I6-Code einbinden, da es die name-Property ja noch nicht gibt:

blue

Eine zusätzliche Definition der Vokabel per Understand-Zeile ist nicht notwendig, weil sie aus der name-Property heraus verstanden wird. Die parse_name guckt trotz eines privaten Namens nach, ob in name etwas steht (Glück gehabt!).

Das ist auch nicht so schön, weil es die Sprachenmix-Problematik von Englisch/Deutsch auf I7/I6 verlagert, aber immerhin ist es möglich, bei der "einspachigen Methode" den Changing Gender korrekt zu verwenden. Nur dran denken: nicht ein "untypable word" 'f.' (wie in deform) wird hier zur Markierung benutzt, sondern ein '#f#'. Das liegt daran, dass aus I7 heraus, keine "untypable words" definiert werden können, deshalb musste eine Alternative her.

Ich habe in der Testversion die Inline-Dokumentation entsprechend geändert. Ich wäre jedoch für jeden Vorschlag dankbar, der es ermöglicht, den CG für beide Methoden (Denglisch/Einsprachig, s. Doku Kap. 4.2 und 4.3) gleichermaßen -- und vielleicht etwas eleganter -- zu verwenden.

Schöne Grüße,

Christian

ChristianB:

Diese Objekte parsen sich über eine parse_name property völlig autark.

So wie ich das sehe, bekommt jedes Objekt eine eigene fette parse_name spendiert, ob es nun privately named ist oder nicht. Und in den meisten Fällen (wenn nämlich eh nur auf die name-Einträge geschaut wird) sind diese parse_names gleich.

Diese parse name soll wohl Fälle wie #003399 abfangen, bei denen verlangt wird, dass die drei angegebenen Wörter genau in dieser Reihenfolge auftauchen.

Deswegen dachte ich, man könnte es mit etwas wie #003399 versuchen. Ich habe mein I7-Jade-Beispiel mal in einer Version erzeugt, in der alle Dinge und Räume privately named sind wie von Dir vorgeschlagen. Dann werden alle Wörter, die normal name-Einträge wären explizit in der parse_name abgefragt, die ich hier mal in all ihrer Pracht abdrucke:

[ Parse_Name_GV258

    original_wn  ! first word of text parsed

    group_wn  ! first word matched against A/B/C/... disjunction

    try_from_wn  ! position to try matching from

    n  ! number of words matched

    f  ! flag: sufficiently good match found to justify success

    w  ! for use by individual grammar lines

    rv  ! for use by individual grammar lines

    g  ! temporary: success flag for parsing visibles

    ss  ! temporary: saves 'self' in distinguishing visibles

    spn  ! temporary: saves 'parsed_number' in parsing visibles

    pass  ! pass counter (1 or 2)

    pass1_n  ! value of n recorded during pass 1

    ;

    if (parser_trace >= 3) print "Two-pass parse_name called^";

    original_wn = wn;

    for (pass = 1: pass <= 2: pass++) {

        wn = original_wn;

        try_from_wn = wn; f = false; n = 0;

        ! On pass 1 only, advance wn past name property words

        ! (but do not do this for ##TheSame, when wn is undefined)

        if ((parser_action ~= ##TheSame) && (pass == 1)) {

            while (WordInProperty(NextWordStopped(), self, name)) f = true;

            wn--; try_from_wn = wn;

        }

            if (NextWordStopped() ~= 'podest') jump Fail_1;

            if (NextWordStopped() ~= '#n#') jump Fail_1;

            try_from_wn = wn; f = true;

            .Fail_1; wn = try_from_wn;

            if (NextWordStopped() ~= 'steinpodest') jump Fail_2;

            if (NextWordStopped() ~= '#n#') jump Fail_2;

            try_from_wn = wn; f = true;

            .Fail_2; wn = try_from_wn;

            if (NextWordStopped() ~= 'steinsaeule') jump Fail_3;

            try_from_wn = wn; f = true;

            .Fail_3; wn = try_from_wn;

            if (NextWordStopped() ~= 'saeule') jump Fail_4;

            try_from_wn = wn; f = true;

            .Fail_4; wn = try_from_wn;

        ! On pass 2 only, match name property words at end

        if (pass == 2)

        while (WordInProperty(NextWordStopped(), self, name)) n++;

        if ((f) || (n>0)) n = n + try_from_wn - original_wn;

        if (pass == 1) pass1_n = n;

    } ! End of pass loop

    if (parser_trace >= 3)

        print "Pass 1: ", pass1_n, " Pass 2: ", n, "^";

    if (pass1_n > n) n = pass1_n;

    wn = original_wn + n;

    if (n == 0) return -1;

    DetectPluralWord(original_wn, n);

    return n;

];

Die Abfragen in der Mitte werden zweimal durchlaufen. Beim ersten Durchgang werden vorangehende, beim zweiten nachgestellte name-Einträge überprüft. Was uns egal sein dürfte, denn Name ist ja leer. (Wenn die Things nicht privately named sind, steht alles in name, aber die Abfragen in der Mitte mit NextWordStopped() fallen weg. Auch hier produzieren beide Durchläufe also dasselbe Resultat. Die zwei Durchläufe sind vielleicht bei komplexeren Objektnamen wichtig.)

Den Changing Gender in name abzufangen, ging leicht, weil man seine eigene WordInProperty schreiben kann, die praktischerweise alle wichtigen Daten übergeben bekommt: Wenn dem gefundenen Wort dann in der genannten Property (meistens name) eine Angabe zum Genus folgt, wird der Changing Gender gesetzt.

Bei NextWordStopped() geht das leider nicht, weil der Routine der Kontext fehlt. Wenn es anstatt

if (NextWordStopped() ~= 'podest') jump Fail_1;

if (NextWordStopped() ~= '#n#') jump Fail_1;

hieße

if (~~NextWordStoppedIs('podest')) jump Fail_1;

if (~~NextWordStoppedIs('#n#')) jump Fail_1;

dann könnte man die Routine über den Template-Mechanismus verbiegen, weil die Routine erkennen könnte, ob das nächste Wort mit einer richtigen Vokabel oder mit einer Genusangabe verglichen werden soll. So geht das aber leider nicht.

Eine andere Chance wäre eventuell noch, irgendwas mit eigenen Tokens zu machen, also zu versuchen, I7 etwas wie #003399 unterzujubeln. Ich bin aber skeptisch. (Und den ganzen Parser quasi durch die Hintertür zu fixen, ist gewiss nicht der richtige Weg.)

Nachtrag: Mit einem I6/I7-Grenzgang kann man tatsächlich etwas wie #003399 realisieren:

003399

Das funktioniert - allerdings nur, wenn das Objekt nicht das letzte Wort ist. Wenn bereits über das Satzende hinaus gelesen wurde, wird alles nachfolgende nicht mehr geparst, obwohl es sich um ein leeres Token handelt, das keine Wörter einliest und immer GPR_PREPOSITION zurückgibt:

Test me:

Du siehst hier eine Steinsäule (darauf eine Jadestatue).

u podest

So etwas kannst du hier nicht sehen.

sieh podest an

Die Säule ist aus glattem Stein gehauen, etwas mehr als einen Meter hoch und oben flach, wie ein Podest.

sieh es an

Die Säule ist aus glattem Stein gehauen, etwas mehr als einen Meter hoch und oben flach, wie ein Podest.

Nachtrag II: Okay, man muss für jeden Genus eine solche Routine definieren und dann den gesamten Bereich "Parse Token" ersetzen:

Include (-

[ ParseTokenStopped x y;

        if (y == CG_NTR or CG_FEM or CG_MAS or CG_PLR) {

                return ParseToken(x,y);

        }

        if (wn>WordCount()) return GPR_FAIL;

        return ParseToken(x,y);

];

... ! Rest gesnippt

Sich schönere Namen für die Tokens auszudenken und das Ganze unter Glulx und mit einem Beispiel in industrieller Größe zu testen, überlasse ich dann aber Dir, Christian.

Martin, danke! Ich hab es ja nicht gewagt, die parse_name hier zu posten; wie oft saß ich schon davor und hab "Ich will da rein ..." vor mich hingemurmelt. Okay, die einzigen Routinen, die man als Einstiegsluke für die 2pass-parse_name benutzen könnte, machen als solche keinen Sinn. Vor meinem geistigen Visionärsauge spukt aber noch das Gespenst einer weiteren Lösung, die setzt aber voraus, dass man in der name-Property noch zur Laufzeit herumschreiben kann und dass man aus Zeichenketten ein Dictionary-Word machen kann.

Ich stelle mir vor, dass man eine I7-Tabelle erstellt, in der die Objekte, für die es Synonyme mit CG gibt, aufgelistet sind.

Zunächst einmal zwingt man Inform für jedes privat benannte Ding eine name-Property auf.

blue

Und dann wird eine Tabelle erstellt, die der Autor dann fortsetzen könnte.

blue

Die Gender-Werte männlich, weiblich, sächlich und Mehrzahl sind schon in der Erweiterung definiert.

Jetzt müsste z.B. in LanguageInitialise() die Tabelle durchgeackert werden und die name-Property des Objekts, die mit Dummy-Wörtern gefüllt ist entsprechend geändert werden (wenn das geht), sodass die name hinter so aussieht

name 'kiste' '#f#' 'word.' 'attr.' 'word.' 'attr.' 'word.' 'attr.' 'word.' 'attr.' 'word.' 'attr.' 'word.' 'attr.' 'word.' 'attr.',

Ich werde so etwas demnächst mal versuchen.

[ EDIT: Oder auch nicht! Gerade habe ich Deine Nachträge gelesen ... das sieht nach einer sehr sehr coolen Lösung aus, die ich unbedingt ausprobieren muss! Danke! ]

Viele Grüße,

Christian

Zitat:

Ich werde so etwas demnächst mal versuchen.

An so eine Lösung hatte ich auch zunächst gedacht, aber das ist ja nur praktikabel, wenn man die Liste der Gender-Zuordungen automatisch erstellt. Dass man dann zu jedem abweichenden Objekt eine Fortsetzung der Tabelle anlegen muss, ist ja wieder wenig intuitiv.

Da scheint mir die Lösung, die ich oben im Cross-Post angegeben habe, etwas schöner und auch natürlicher. (Vorausgesetzt, dass sie immer funktioniert, aber im Moment sehe ich nicht, wieso nicht) Wenn die Tokens [m], [f], [n] und [p] noch frei wären, wäre das soch sehr elegant: #003399.

Das funktioniert nach ersten Tests für Objekte, die publically-named[i] oder [i]privaltely-namedsind und sogar für erweiterte Kombinationen:

003399

Martin, das ist einfach genial!

Und genial einfach in der Verwendung (wenn man sich das jetzt so anschaut). Mir war gar nicht nicht klar, dass man die Understand-Token auch für die Synonyme gezielt nach I6 übersetzen kann -- für die Verben wird das ja schon lange so gemacht.

Meine ersten Tests zeigen keine Probleme auf, mal sehen, was die folgenden Power-Tests so ergeben.

Die Token [m], [f], [n] und [p] sind alle noch frei, somit sieht die Vokabel-Definition mit CG auch wieder richtig nach I7 aus.

Die vorige Methode mit den "#N#"-Attributen war nicht schön, zumal die Attribute ja Vokabeln waren, die irgendwie für den Parser getarnt werden mussten.

Also, wenn das überall klappt, dann lohnt sich der Versionssprung tatsächlich.

Ein riesengroßes DANKESCHÖN für diese elegante Lösung!

Christian

[Edit: Eine ganze Menge Varianten später sind die CG-Token immer noch nicht in die Knie gegangen ... :-)

An der ParseTokenStopped(), die aufgebohrt werden musste, wäre ich ganz sicher verzweifelt, das hätte ich nie gefunden ...

Die Token heißen in I6 jetzt übrigens CG_NEUTER_TOKEN usw. Noch ein paar Tests, dann lade ich eine aktualisierte Testversion hoch.]

So, ich habe jetzt noch mal ein wenig was ausprobiert -- es folgt ein Beispiel-Code, der die Standard-Denglisch-Methode zum Definieren von Objekten benutzt (es scheint keinen Unterschied zu machen, ob Objekte privately-named oder publically-named sind):

blue

Alle Beispiele, bis auf eines, funktionieren. Beim Test "Tassen" gibt es ein Problem, warum, weiß ich noch nicht.

Test Tassen:

[1] nimm zwei becher

Tasse: In Ordnung.

Tasse: In Ordnung.

[2] u becher

(die Tasse)

Die Tasse ist leer.

[3] leg ihn hin

Der Fußboden ist bereits hier.

Interessant finde ich, dass in Z-Code (wo die Vokabeln intern maximal nur 9 Zeichen lang sind) "Bistrotisch" und "Bistrotischchen" offenbar doch unterschieden werden.

Test Tisch:

[1] u bistrotischchen

Du siehst nichts Besonderes an dem Bistrotisch.

[2] pronomen

Die Pronomen beziehen sich im Moment auf Folgendes:

"er": der Bistrotisch

"sie": die Tasse

"es": der Bistrotisch

"ihn": der Bistrotisch

"ihm": der Bistrotisch

"ihr": die Tasse

"ihnen": nicht gesetzt

"damit", "darauf", usw.: der Bistrotisch

"ihm/r": der Bistrotisch

[3] nimm es

Der Bistrotisch ist fest.

[4] u boden

Du siehst nichts Besonderes an dem Fußboden.

[5] u bistrotisch

Du siehst nichts Besonderes an dem Bistrotisch.

[6] pronomen

Die Pronomen beziehen sich im Moment auf Folgendes:

"er": der Bistrotisch

"sie": die Tasse

"es": der Bistrotisch

"ihn": der Bistrotisch

"ihm": der Bistrotisch

"ihr": die Tasse

"ihnen": nicht gesetzt

"damit", "darauf", usw.: der Bistrotisch

"ihm/r": der Bistrotisch

[7] nimm ihn

Der Bistrotisch ist fest.

Eine aktualisierte Vorab-Testversion 2 ist jetzt online. In der Inline-Doku wird der CG in Kapitel 4.5 beschrieben.

Jetzt kann das I7-Update von mir aus kommen. Nochmals herzlichsten Dank an Martin!

Grüße,

Christian

Christian:

Alle Beispiele, bis auf eines, funktionieren. Beim Test "Tassen" gibt es ein Problem, warum, weiß ich noch nicht.

Hmmm. Das hat scheint's etwas mit dem Dismbiguieren der verschiedenen Tassen zu tun. In I6 passiert das auch. Was aber genau passiert, weiß ich nicht so recht. Wird der changing gender bei der Meldung "(die Tasse)" zurückgesetzt?

Christian:

Interessant finde ich, dass in Z-Code (wo die Vokabeln intern maximal nur 9 Zeichen lang sind) "Bistrotisch" und "Bistrotischchen" offenbar doch unterschieden werden.

Beider Wörter werden gleich behandelt, aber 'bistrotisch' hat den Genus des Objekts und steht daher in name, 'bistrotischchen' steht, da es aus zwei Tokens, die aufenader folgen müssen, besteht, fest verdrahtet in der 2-pass parse_name.

Der erste Durchgang überprüft erst die name, dann die Tokenketten und der zweite Durchgang macht's genau andersherum. Beim ersten Durchgang wird 'bistrotisch' erkannt und der CG in Ruhe gelassen, aber beim zweiten Durchgang wird 'bistrotischchen' erkannt und der CG gesetzt.

Probier's mal: Auch wenn man 'bistrotisch' sagt, ist der changing gender gesetzt und 'es' bezieht sich auf den Tisch.

(Wenn ich aber spaßeshalber eine Bistrotischdecke auf das Bistrotischen lege, funktioniert's wieder nicht, vermutlich aus denselben Gründen wie bei den Tassen.)

Martin:

Wird der changing gender bei der Meldung "(die Tasse)" zurückgesetzt?

Sieht ganz danach aus. In der Routine Gender() gibt's einen heißen Kandidaten; wenn ich den auskommentiere, wird die Tasse korrekt erkannt -- allerdings eine Tasse im Inventar, aber das soll ja so sein.

    ! Genus zurücksetzen

    !GenderNotice(obj, 0);

    [....]```

Du hast Dir dabei ja sicher was gedacht. Vielleicht muss das Zurücksetzen nur bedingt geschehen?

[Edit: Oder stammt das noch aus der Zeit, zu der auch die Ausgabe-Routine für Pronomen für einen Zug angepasst wurde, da gab's doch mal irgend so etwas, oder?

```[ PersonalPron obj k;

    print (string) PersonalPronouns-->(4*k + Gender(obj, true));

];```

Dies ist die einzige Stelle, wo Gender() mit flag==true aufgerufen wird, d.h. der CG berücksichtigt werden soll (wird er aber hier nicht so recht).

Ich konnte noch keine Nachteile mit der auskommentierten Fassung finden. ]

Es gibt jetzt eine neue Vorab-Testversion, in der der das Tassen-Beispiel korrekt funktioniert.

Der Genus eines Objekts und auch der geänderte Genus können jetzt als Werte befragt und in Say-Phrasen verwendet werden (siehe Kap. 4.5 und Kap. 4.6 der Inline-Doku). Bei der Verwendug einer Textersetzung für ein Personalpronomen wird der Changing Gender nicht mehr berücksichtigt.

Grüße,

Christian