TBD Manual: G.5. Word order

[tajmone]

Appendix G: Localization, section G.5. Word order (links to master).

Marked as TBD in original Manual:

Text about how the rigid word order (verb first, possibly prefixed with a noun) that Alan imposes. Or does it? With the noun first is it possible to implement “das buch nehmen” with the syntax take = (o) nehmen?

---

Preview Links

• App. G.5. Word order (master)
• App. G.5. Word order (dev-man)

[tajmone]

As mentioned in #61, it's indeed currently possible to create syntaxes starting with a parameter.

I see the point of the das buch nehmen example in relation to localization — i.e. that it's worth mentioning this in App G. for languages that naturally rely on verbal constructs of this type.

But ... beside a passing note, I don't really see how this topic should belong to localization specifically; I rather think we should expand on this more in the SYNTAX/VERB sections, for it open up much potential for verb constructs like "Bob, take apple", which are common use in most IF systems, and chances are that authors would try to implement them in Alan too (for sure, seasoned IF players will attempt such commands).

So, maybe a brief not in App. G.5 and then an xref link to a more indepth description elsewhere in the Manual.

[thoni56]

Agreed. The "parameter first" text should be woven into the current section on Syntax. And as you say, a brief note should suffice here.

What I'm imagining is that there are two word order "issues" in localization that should be addressed, one is the object/verb order the other the noun/adjective order. Both should be noted here and a suggested solution to them should be presented.

As the first one is already handled, remains the second one. And I decided to keep the TBD for that (in 72c5f0d).

[tajmone]

the other the noun/adjective order.

Yes, I remember this problem because it's frequent in Italian:

Italian	English
> prendi la mela rossa	> take the red apple
> prendi la grossa mela	> take the big apple
> prendi la mela grossa	> take the big apple
Puoi vedere una grossa mela.	You can see a big apple.

But you can't say "rossa mela" in Italian!

I'm not quite sure about the rules that determine when an adjective must follow the noun in Italian, but sometimes you have to do it (and you know it just because it sound correct), whereas sometimes you can either place it before or after the noun, with a slightly different emphasis.

I remember that this issue can be problematic in Italian games, where you'd like the player to be able to address the object either by it's mere noun, or with the following (or preceding) adjective — the main issue is when you have multiple objects sharing the same noun but different adjectives.

Indeed, it would help internationalization if ALAN could provide a more sophisticate way of defining adjective around nouns (i.e. before and after).

I'm not sure how this could be done without disrupting the current syntax; the only thing that comes to my mind is the possibility of explicitly marking noun by the presence of a *:

NAME mela* rossa.

where, in the above example, the * overrides the default <adjective> <noun> pattern by indicating the non-standard position of the noun in the NAME clause.

I guess the hard part is not so much handling it in the ALAN source adventures, but implementing in the input parser — it looks like this would introduce a new layer of complexity in the code that tries to identify the parts of speech, and the whole internal disambiguation process.

I was wondering if building and keeping an internal dictionary of adjectives would help, based on the assumption that and adjective would never be a noun. This could potentially help disambiguating complex situations where the input might need to be evaluated against different objects that take the adjective either before or after the noun, and some which accepts both positions. If we know that "red" is an adjective (because the author defined it) we could expect that the word red in the player input should always be an adjective too (unless there's also a noun explicitly defined with the same word).

I'm not sure how the whole semantic parsing of input works, and whether or not the above makes any sense, but from the little I know about parsing input commands, unraveling natural sentences can easily get entangled, even with simple commands like those used in IF games.