Removing the space after an article (definite and undefinite)

Authoring Inform 7
1

I’d like to know if there’s an easy way to remove the space after an article. In French, there’s a contraction before a vowel (for example, “l’arbre” instead of “le arbre”). This contraction is done automatically for the standard articles, but not when you change them (for example, when you want the indefinite article to be the same as the definite one).

If I write:

The indefinite article of the arbre is "l[']".

Then in-game you obtain l' arbre (with a space).

To have complete control over the articles, I thought about using the Inform 6 articles property as described in page 272 of the DM4:

! Example taken from the DM4.
Object "haricot"
    with articles "Le " "le " "un ",

We can see there is a space after the articles, so I thought that this property overode the spacing. However, in Inform 7, if we write the fololwing:

Include (-
    with articles "L'" "l'" "l'",
-) when defining the arbre.

The space is still printed, so I guess that something has changed in Inform 7 (or that the DM4 is wrong, I haven’t tested with Inform 6).

The only workaround I found is to make the object proper-named and to put the article in its printed name:

The arbre is a proper-named thing. The printed name is "l'arbre".

But then the casing will be wrong if the object is printed at the beginning of a sentence.

So would there be another way to remove the space? I’m guess it will be tinkering with the Inform 6 templates.

1 Like
2

My fairly wild guess is that it comes from the spaces printed in the fifth and seventh lines of PrefaceByArticle in the template file Printing.i6t:

[ PrefaceByArticle obj acode pluralise capitalise  i artform findout artval;
    if (obj provides articles) {
        artval=(obj.&articles)-->(acode+short_name_case*LanguageCases);
        if (capitalise)
            print (Cap) artval, " ";
        else
            print (string) artval, " ";
        if (pluralise) return;
        print (PSN__) obj; return;
    }

    i = GetGNAOfObject(obj);
    if (pluralise) {
        if (i < 3 || (i >= 6 && i < 9)) i = i + 3;
    }
    i = LanguageGNAsToArticles-->i;

    artform = LanguageArticles
        + 3*WORDSIZE*LanguageContractionForms*(short_name_case + i*LanguageCases);

    #Iftrue (LanguageContractionForms == 2);
    if (artform-->acode ~= artform-->(acode+3)) findout = true;
    #Endif; ! LanguageContractionForms
    #Iftrue (LanguageContractionForms == 3);
    if (artform-->acode ~= artform-->(acode+3)) findout = true;
    if (artform-->(acode+3) ~= artform-->(acode+6)) findout = true;
    #Endif; ! LanguageContractionForms
    #Iftrue (LanguageContractionForms == 4);
    if (artform-->acode ~= artform-->(acode+3)) findout = true;
    if (artform-->(acode+3) ~= artform-->(acode+6)) findout = true;
    if (artform-->(acode+6) ~= artform-->(acode+9)) findout = true;
    #Endif; ! LanguageContractionForms
    #Iftrue (LanguageContractionForms > 4);
    findout = true;
    #Endif; ! LanguageContractionForms

    #Ifdef TARGET_ZCODE;
    if (standard_interpreter ~= 0 && findout) {
        StorageForShortName-->0 = 160;
        @output_stream 3 StorageForShortName;
        if (pluralise) print (number) pluralise; else print (PSN__) obj;
        @output_stream -3;
        acode = acode + 3*LanguageContraction(StorageForShortName + 2);
    }
    #Ifnot; ! TARGET_GLULX
    if (findout) {
        if (pluralise)
            Glulx_PrintAnyToArray(StorageForShortName, 160, EnglishNumber, pluralise);
        else
            Glulx_PrintAnyToArray(StorageForShortName, 160, PSN__, obj);
        acode = acode + 3*LanguageContraction(StorageForShortName);
    }
    #Endif; ! TARGET_

    Cap (artform-->acode, ~~capitalise); ! print article
    if (pluralise) return;
    print (PSN__) obj;
];

And maybe what you need to do is add an extra flag on that to check whether the space needs to be printed, and set a flag on things with names like “arbre” and “hibou” that somehow gets passed to PrefaceByArticle–maybe through DefArt and CDefArt? But this goes way farther than anything I’ve ever been able to pull off with I6 template hacking.

3

Sorry for the late reply…

I haven’t tested yet, but it would seem you are right, it comes form the lines you mentioned. In the same routine in the Inform 6 library, we can see that the space is not printed.

And best of all (if I understand correctly, but feel free to correct me), it only applies when the articles I6 property is set, so I could just suppress the space in that case and it won’t change he normal behavior otherwise. :grinning:

So the behavior has changed in Inform 7, but I wonder why one would have bothered at all, since Inform 7 does not use articles, as stated in Definitions.i6t:

Property articles; ! not used by I7, but an interesting hook in the parser

Would removing the space be a good suggestion/bug report to make? Since no space is printed in the normal course, when articles is not provided. (The spaces are “hardcoded” in the LanguageArticles array.)

I think I’ll just suppress the space in the I6 template, and instruct French users to write the following when needed:

Include (-
    with articles "L'" "l'" "l'",
-) when defining the arbre.

It’s so rarely used it’d be easier than to tinker with the template.

Thanks a lot, it really helped me! I’ll make the changes soon and see if it works with no side-effects

4

Sure! I’d guess it wouldn’t be a bug report, because it doesn’t look like anything here is behaving in a way that’s not specified, but OTOH the uservoice site is pretty moribund. I don’t know if you and other people working on non-English Inform have a way of communicating with the team.

1 Like
5

In fairness, “Inform’s behavior doesn’t line up with how this natural language works” seems like a reasonable bug report. Especially since I6 had/has ways to deal with this in localization.

1 Like