Spanish Scenery Attribute

[Rich15]

@tajmone, following the new English Foundation v0.3.0 update on the scenery class (now an attribute), I wanted to do the same in the Spanish Library. However I wanted to discuss some things before I do it.

messages_library.i module

I see you created this new module with some Library's recurring messages. Should the Spanish Library also include this?

scenery translation

We already talked about escenario being a confusing name and an improper translation, so I was thinking of changing it with this new update. I think "decoración" (best fit, IMO) or "accesorio" would be good candidates, but just wanted to know what you think. 'scenery' is hard to translate to Spanish, so the best we can do is choose a word that conveys what we want.

---

Once I finish updating the scenery attribute I will commit it to the dev_alan-es branch so you can check for any improvements (and also update the docs and rake files).

Also @thoni56, @tajmone , I hope you had happy holidays with your loved ones, and wish you a happy new year! 🎄 🎊 .

[tajmone]

Ciao @Rich15! sorry for the late reply but I wanted to keep off the PC for a few days.

messages_library.i module

I see you created this new module with some Library's recurring messages. Should the Spanish Library also include this?

Indeed, the Spanish and Italian libraries will need that module much more than the English library.

As you can seek by peeking at the lib_messaggi_libreria.i module of the ALAN StdLib Italian project, I've made heavy use of string attribute messages to cover GNA in library responses.

The real challenge for languages like Italian and Spanish, which involve also gender beside number, is coming up with generic snippets that are reusable across different responses.

In the English library you can often get away with using the $v special symbol to obtain the infinitive of the verb — e.g. "You can't $v $+1!" — since the imperative and infinite forms overlap in English ("eat the apple" → "You can't eat the apple!"). But in Italian and Spanish things are not that easy.

I haven't started working on the library messages library in the Italian Foundation yet, but I'll be reusing as much as I can the lib_messaggi_libreria.i module for the Italian StdLib, since these are well tested messages.

You'll see that it will come natural to move toward generic messages as you work on the module. E.g. to cover responses for CHECKs blocking an action, you'll need some generic response like: "$+1 [is|are] not something you can" followed by the infinite form of the verb, which is specified on a per-VERB basis.

The tricky part is coming up with sentences that avoid bringing up gender and number, if possible, in order to avoid having to provide multiple variations of the same message (i.e. singular vs plural, masculine vs feminine), since their combinations quickly lead to something like:

• some-message_ms &rarr: masc. sing.
• some-message_fs &rarr: fem. sing.
• some-message_mp &rarr: masc. plur.
• some-message_fp &rarr: fem. plur.

For example, in Italian the response "$+1 non [è/sono] qualcosa che puoi" is pretty versatile, since the term "cosa/qualcosa" it's gender neutral, and you only need a singular and plural variation of the response attribute.

I think in Spanish the situation is very similar, so it's only a matter of finding generic messages which will apply to different verbs, and do so with the least number of variations possible.

Of course, for verbs including prepositions we might need special responses covering the prepositions — e.g. in Italian for the con (with) I'd use the following messages for verbs where the second parameter is governed by the "con" preposition:

• impossibile_con_p2_sg — "$+2 non è qualcosa con cui poter" (sing.)
• impossibile_con_p2_pl — "$+2 non sono qualcosa con cui poter" (plur.)

Where in the actual VERB response, e.g. for the verb "aprire con" (open with):

Syntax aprire = apri (ogg) con (strumento)

I'd use something like this to report an unsuitable second parameter:

  else
    If obj2 is plural
      then say msg:impossibile_con_p2_pl.
      else say msg:impossibile_con_p2_sg.
    End if. "aprire $+1!"

So, the same attributes group can be used with any verbs taking the "con" preposition, and so one.

The whole idea is to avoid redundancy by moving into string attributes recurrent message snippets, which also allows to control library responses in a single place. Of course, in some cases this might not be necessary, e.g. if a custom message for a specific VERB is preferable. But as a general rule, library error responses should look pretty standard and similar, which makes them easier to recognize and less intrusive and dis tractive on the game narration (error messages are a necessary "evil", so to speak, whereas success responses are what naturally moves the story onward).

scenery translation

We already talked about escenario being a confusing name and an improper translation, so I was thinking of changing it with this new update. I think "decoración" (best fit, IMO) or "accesorio" would be good candidates, but just wanted to know what you think.

They both sound good to me, and I'd probably pick the first one just because accesorio is more likely to be used as a custom class name by game authors (classes and attributes don't conflict, so they can have same names, but it can be confusing in real practice). Also, "accesorio" might have an active role in a game (e.g. a key or a lock-pick to open a door, or other type of tools), whereas a "decoración" is always something with a mere aesthetic role.

'scenery' is hard to translate to Spanish, so the best we can do is choose a word that conveys what we want.

The same in Italian, and I haven't yet found a proper term either. I'll probably use "decorazione" too, following your steps, so at least we have consistency across the Italian and Spanish library.

Even the English library could adopt decoration instead of scenery, when you come to think about it. Even in English "scenery" doesn't convey the right message — a "scenery" is a nice sight, like the sunset on a beach, the dunes in the desert, and does not describe a function (like "scenic prop" does).

---

Once I finish updating the scenery attribute I will commit it to the dev_alan-es branch so you can check for any improvements (and also update the docs and rake files).

Sounds great! I don't think that we'll need to update the Rakefile since it's designed to pick-up dependencies by folder/files patterns, so adding a new module doesn't require any changes.

Also @thoni56, @tajmone , I hope you had happy holidays with your loved ones, and wish you a happy new year!

Thanks, and happy new year to you too!

[tajmone]

scenery translation (2): ornamental

Maybe instead of "decoration" we could translate it as "decorative", since it's an attribute — i.e. Is decorativo. This would still leave room for a custom class name decoration if there's a need on the author end.

In Italian there's also the term "ornamentale" to indicate a merely decorative function — i.e. Is ornamentale. I believe the Spanish equivalent is ornamental.

In English ornamental would also fit well, as it indicates a property/function of the object, so it fits well as an attribute to distinguish game objects with no active role.

@thoni56, would do you think about switching from scenery to ornamental?

[thoni56]

I think that is a very good choice! Very descriptive for the types of items we are thinking about here.

(And a Happy New Year!)

[tajmone]

Ornamental Attribute Implemented!

I've just published Foundation EN v0.4.0 which renames to scenery attribute to ornamental, as discussed here. It looks better, and it's now clearer how the attribute affects the objects — with the added benefit of being easier to translate in other locales.

I've also updated the English documentation accordingly.

Still on the topic of "scenery/ornamental" objects, see also my new proposal at #58.

[tajmone]

Italian Scenery Implemented!

@ricardo, I've just published the updated Foundation Italian with the new scenario attribute, so you might want to have a look at the changeset since they are closer to those required by the Spanish library.

I didn't have time to actually add the tests, like I did for the English library, but they seem to compile fine, and some manual tests seemed to work fine too.

Sorry for the late replies, but after Christmas day I got very sick and only got back at the PC in past three days — needless to say, tons of procrastinated work and chores have piled up in the meantime.

Buzz me when you start working on the Spanish update; I'd like to join the work, especially regarding updating the Vampiro adventure to use the new scenery attribute — I'm still trying to study the adventure source, but sometimes I find it hard to decipher what's what due to lack of understanding of the language, but I'd like to catch up with the adventure since I think we should also implement it in the other library locales, as a sample adventure along with Cloak of Darkness, since Vampiro is a more fleshed-out demo compared to Cloak (and a full-fledged adventure in its own right).

From what I read in the source comments, I also think that it's not entirely completed, there might be some details still unimplemented. But since the Vampiro project is well documented online, we can easily fix that. In any case, we should tweak its source to make out the most of the Foundation features, where these have diverged from the original library.

[tajmone]

Spanish Lib v0.5.0 Ready to Merge

@Rich15, I've taken the liberty of applying all the pending scenery related changes to the Spanish library, which are now ready to be squashed and merged from dev_alan-es to main branch.

For the time being, I kept all the commits separate, so it's easier for you to track each single feature implementation, one commit at the time. But if everything is OK with you, it's ready to merge as its (all details taken care of).

This is going to be v0.5.0 of the library (see CHANGELOG for the details),

As far as I've seen, everything seems OK. You might want to inspect the following:

• mensajes_libreria.i (new module):
  • Check message attributes identifiers, if they are OK.
  • Check that all messages strings are in correct Spanish.
• examinar.i — the alternative syntaxes (or Synonyms) mira/miro (LL 132) and busca/busco (LL 179) for the verbs mirar_en and buscar are not defined. Is there a reason for this? or is it just an oversight? (see also scenery.a3t transcript)
• scenery.alan (LL 48) — Check that my added translation is in correct Spanish (see -- @CHECK comment).

The rest is pretty much just tons of similar code fixes and additions, applied to almost every library verb CHECKs — all of which are fully covered by the updated test suite, so not much that can have gone wrong there (test and Vampiro transcripts would have caught any problems).

If you're happy with the changes, feel free to squash into main. If you think that there are still some changes to be done, let me know.

[tajmone]

Spanish Foundation v0.5.0 Published

@Rich15, I hope you don't mind me taking the liberty of publishing the new Spanish version with the scenery changes.

It's just that, because the changeset included changes to the commonly shared PORTS_STATUS.md document, it was preventing me from updating the Italian library, which would also edit that same file leading to conflicts — unfortunately this status tracking system involves markdown tables which are edited with each new library version, where each locale touches the status table, so conflict solving of markdown files can become a bit annoying.

In the future I'll keep all library changes strictly within the library sub-directory, and update the PORTS_STATUS.md document in a separate commit, to avoid possible conflicts (e.g. in local rebasing, etc.). If each locale manages to keep its commits changes confined to it own directory it would be much better in terms of allowing each other to freely rebase our own local dev branches when main is updated. Since the Libraries Status document is relatively new, I didn't keep this into account.

Anyhow, I'm quite confident that all changes to the Spanish library should be fine, and in the worst case scenario we can always fix minor problems in next update (we're still in Beta after all).

I'll now replay the last changeset on the Italian library, while my memory is still fresh — otherwise I'll forget the various steps.