PunyInformDE ist die deutsche Übersetzung der aktuellen Version von PunyInform, erweitert um grammatikalische Lösungen für die deutsche Sprache, insbesondere aus deform.

Erhältlich hier: https://github.com/IkeC/PunyInformDE

Kommentare, Anregungen und Mitarbeit ausdrücklich erwünscht! Gerne trage ich Interessierte auch als Contributors ein, ansonsten gerne einfach PRs oder Issues einstellen. Hier lese ich natürlich immer mit.

Freue mich schon auf eure Spiele.

Wow! Sehr schnelle Umsetzung des Prototypen samt Beispiel und Testsuite. Und für Leute wie mich, die gerne lange theoretisieren, gibt's sogar schon umfangreiche Dokumentation. Herzchen!

Erster Winztest: Ich musste in meiner völligen Ignoranz in globals.h, puny.h und globals_de.h die Anweisungen

Include "de/blablabla_de.h"

mit absoluten Pfaden ersetzen. Sonst beschwerte sich der Parser, sie würden nicht gefunden.

Habe die README dazu etwas erweitert ("Quick Start") und einige kleinere Bugs gefixt, außerdem ist jetzt ein .z3-Build im Standard-Workflow enthalten. Gerne also nochmal aktuellen Stand pullen!

> inform-6.45 +include_path=../PunyInformDE/lib  -v5 main.inf out.z5
Inform 6.45 (in development)
"../PunyInformDE/lib/globals.h", line 7: Fatal error: Couldn't open source file "de/globals_de.h"

Ich bekomme den gleichen Fehler wie Hannes.

Das scheint mir aber ein Fehler (oder vielleicht nur das gewünschte Verhalten) des Inform6-Compilers zu sein: Wenn die einzubindende Datei einen Separator für Verzeichnisse enthält, wie den Schrägstrich bei "de/globals_de.h", wird der angegebene Include-Path nicht verwendet.

Ich vemute, dass Ike unter Windows arbeitet und der Seperator dort ein Backslash ist, obwohl man in der Inform-Datei (wie bei Inlcudes in C) eine normalen Schrägstrich angibt und die Regel oben daher nicht zur Anwendung kommt.

Ich weiß auch nicht, wieso es diese Regel gibt. C macht es jedenfalls wie von Ike vorgesehen. Ich vermute, dass diese Regel nur für absolute Pfade, also "/usr/local/puny/" oder so gelten soll. Für relative Pfade ist sie meiner Meinung nach Quatsch.

(Das Ganze passiert in den Funktionen translate_in_filename und contains_separator in inform.c. Als Fix kann man die letzte Funktion ersetzen durch:

static int contains_separator(char *name)
{
    return (*name == FN_SEP);
}

(Das ist mit der heißen Nadel gestrickt und funktioniert nicht für Windows-Pfade, die ja einen Laufwerksbezeichner haben können.)

Danke, Martin! Also ein Fall für den Inform-Bugtracker. Ist ja erstmal nicht fatal, habe wie gesagt absolute Pfade rein geschrieben.

Also ein Fall für den Inform-Bugtracker.

Da bin ich mir nicht sicher. In Abschnitt 38 des Inform Designers' Manual steht über die Include-Direktive:

(The rules for how Inform interprets "filename" vary from machine to machine: for instance, it may automatically add an extension such as “.inf” if your operating system normally uses filename extensions and it may look in some special directory. Run Inform with the -h1 switch for further information.)

Wenn man sich mit -h1 die Nomenklatur für Dateinamen anzeigen lässt, wird einem unter anderem gesagt:

If the name contains a '/' character (so it's already a pathname), it isn't changed.

Ich denke also, dass der eigentliche Fehler ist, dass es bei Ike unter Windows funktioniert hat. Wenn das so ist, müsste man sich gewiss eine andere Organisation des Puny-Codes oder zumindest eine neue Include-Strategie überlegen.

(Die klare Trennung vom englischen Basis-Puny und den deutschen Ergänzugen bzw. Änderungen finde ich gut. Ein Problem mit deform war, dass es diese Trennung nicht gab und so Änderungen in der Inform-Lib nicht nachgezogen wurden. Allerdings lässt sich auch nicht immer alles so genau trennen.)

Uff, was für ein unnötiger Krampf. Tendiere dazu, den de-Unterordner aufzulösen, dann muss eben das _de-Suffix für die Dateinamen zur Unterscheidung erstmal ausreichen. So ganz stringent ist die Trennung ohnehin nicht.

Uff, was für ein unnötiger Krampf.

Ja, schade, dass die intuitive Variante nicht überall geht.

Tendiere dazu, den de-Unterordner aufzulösen ...

Oder die Struktur so lassen, das "de/"-Präfix aus den internen Includes entfernen und mit zwei Pfaden arbeiten, also +lib,lib/de oder ++lib ++lib/de. (Scheint beides zu gehen. Man muss es ja sowieso nur einmal mit !% in den Kopf der Hauptdatei schreiben.)

Noch besser. Machen wir so.

Issues are disabled for the selected repository.

Ich schreibe dann einfach mal hier:

Manuell gesetzte Artikel werden nicht dekliniert.

Object id "Personalausweis"
    with
        article "dein",
        name 'personalausweis' 'pass' 'ausweis',
        description "Du magst dieses alte Foto nicht. Du guckst darauf wie ein Reh im Scheinwerferlicht.",
    ;

> i
Du hast dein Personalausweis.

(The) steht immer im Nominativ

Object id "Personalausweis"
    with
        name 'personalausweis' 'pass' 'ausweis',
        description "Du magst dieses alte Foto nicht. Du guckst darauf wie ein Reh im Scheinwerferlicht.",
        before [;
            Drop:
                print_ret (The) noun, " behältst du besser bei dir.";
        ],
    ;

> wirf ausweis
Der Personalausweis behältst du besser bei dir.

Issues sind jetzt aktiviert, aber hau ruhig raus.

(The) steht immer im Nominativ

Ich denke, hier sollten (DE_der), (DE_den) oder (DE_dem) benutzt werden, von denen es aber noch keine großen Varianten für den Satzanfang gibt. (Das Großschreiben ist aber mit dem Argument p_cap in _DE_PrintDefWithName schon vorgesehen.)

Die Meldungen in messages_de.h mischen die neuen deutschen Routinen munter mit den bestehenden (The), (the), (CTheyreOrThats) usw. Vermutlich ist es besser, hier konsequent die deutschen Varianten zu verwenden.

Ich glaube, es ist ein Fehler, hier zweigleisig zu fahren und die englischen PSN-Routinen zusätzlich zu (DE_der) und Konsorten zu unterstützen. Die Ausgaberoutinen sollten komplett von der deutschen Lib beigesteuert werden und die ursprünglichen (The), (the) usw in deutschen Spielen nicht verwendet werden. Das macht allerdings gewiss Ärger, wenn man das Original-Puny und Puny-DE sauber trennen möchte.

Danke fürs fleißige Kommentieren und Testen. Issues in GitHub sind weiterhin sehr willkommen, danke dafür Hannes.

Alle mir bekannten Probleme sind jetzt behoben, soweit möglich unter Berücksichtigung eurer Anmerkungen.

Wie hättest du das gerne? Soll ich meine Tickets selbst schließen, sobald es bei mir läuft?

Ja, gerne!

Martin:

(The) steht immer im Nominativ

Ich denke, hier sollten (DE_der), (DE_den) oder (DE_dem) benutzt werden, von denen es aber noch keine großen Varianten für den Satzanfang gibt. (Das Großschreiben ist aber mit dem Argument p_cap in _DE_PrintDefWithName schon vorgesehen.)

Ike, wie empfiehlst du es? (The) verwenden, oder lieber spezifisch (DE_den) usw.?

Explizit wie Martin sagt, (The)/(the) geht aber auch.