Question, It is possible to have a report with i18n #145

Activity

1. Scot3004

   changed the title [-]Question, It is possible to have a report with i18n based on beat[/-] [+]Question, It is possible to have a report with i18n[/+] on Jul 31, 2024
2. perrygoy commented on Jul 31, 2024

   

   perrygoy

   on Jul 31, 2024

   Last edited by perrygoy

   Member

   More actions

   This is something that i've thought about quite a lot—how to support other languages.

   I'd really love to be able to easily have translations available. For the Narrator's log, yes, it really would be as simple as having a different beat for the perform_as function, like:

   from screenpy import See, Silently, beat
   
   class Ver(See):
       @beat("{} ve si {question_to_log} es {resolution_to_log}.")
       def perform_as(self, the_actor: Actor) -> None:
           Silently(super(Ver, self)).perform_as(the_actor)  # might work?

   Edit: I just realized this probably wouldn't work very well with the Silently, because everything inside of this See would be muted. But without the Silently, the English text would also be read. It's a bit tricky.

   That would allow the Narrator to read the Spanish, as long as you made subclasses for all of the Actions you used. The tests themselves would still be using the English methods, though.

   Making the methods be Spanish, too, you might be able to do...

   class UnActor(Actor):
       llamado = Actor.named
       quién_puede = Actor.who_can
       # ...

   That feels a little strange, but i think it should work!

   As i said, i'm very interested in this. If you try one of these approaches, can you share how successful it was?

   👍React with 👍1Reacted by Sergio C. Orozco Torres
3. perrygoy commented on Jul 31, 2024

   

   perrygoy

   on Jul 31, 2024

   Member

   More actions

   We might need to do some work to more easily allow translations, like Django's _ function or something. I'll be thinking more about this!
4. bandophahita commented on Aug 13, 2024

   

   bandophahita

   on Aug 13, 2024

   Contributor

   More actions

   I'm not well versed in other languages but I have thought about multi language support and one aspect we'll likely need to figure out is how to handle grammar issues depending on the language.

   The current structure of the screenplay pattern is actor-centric because that's how English has a tendency to flow.
   Subject -> verbs -> noun. "I go to the market."

   Whereas some languages might structure the sentence "To the market, I go."
   My hunch is some languages will just end up reading like they ran though google translate; which I'm not sure can be helped.
5. Scot3004 commented on Aug 13, 2024

   

   Scot3004

   on Aug 13, 2024

   Author

   More actions

   Spanish can be as well actor centric, but for instance in english we have a passive voice like
   The windows have been cleaned.
   https://learnenglish.britishcouncil.org/grammar/english-grammar-reference/active-passive-voice
6. bandophahita

   added

   questionFurther information is requestedFurther information is requested

   on Apr 15, 2026
7. bandophahita commented on Apr 15, 2026

   

   bandophahita

   on Apr 15, 2026

   Last edited by bandophahita

   Contributor

   More actions

   Thinking a little more about this -- There are a couple of things to consider for language translation; The code and the logging.

   My initial though was aliases could be created for each language but that doesn't translate any of the arguments.

   class UnActor(Actor):
       llamado = Actor.named
       quién_puede = Actor.who_can
   
   UnActor.llamado(name="Marcel")  # little awkward in those cases where named arguments are utilized.

   I read about using decorators to make argument aliases, perhaps something similar could be done here?

   class UnActor(Actor):
       llamado = translate_method(method=Actor.named, kw={"name" : "nombre"})

   ---

   Secondly, the strings used by pacing (beat, aside, etc), describes, matchers (resolutions) would also need to be translated and swapped out.

   class See:
       def describe(self) -> str:
           """Describe the Action in present tense."""
           return f"See if {self.question_to_log} is {self.resolution_to_log}."  # <--- this
   
       @beat("{} sees if {question_to_log} is {resolution_to_log}.")  # <--- this
       def perform_as(self, the_actor: Actor) -> None:
           """Direct the Actor to make an observation."""
           if isinstance(self.question, Answerable):
               value: object = self.question.answered_by(the_actor)
           else:
               # must be a value instead of a question!
               value = self.question
               aside(f"the actual value is: {represent_prop(value)}")  # <--- this ** needs a callback?
   
           reason = ""
           if isinstance(self.question, ErrorKeeper):
               reason = f"{self.question.caught_exception}"
   
           assert_that(value, self.resolution.resolve(), reason)

   The 3rd string needs a value passed in, so static strings aren't sufficient. It would need to be a function.

   From a maintainability standpoint, I'm thinking we would want to create string var modules (for each language) which are then referenced based on runtime language configuration.

   class See:
       def describe(self) -> str:
           """Describe the Action in present tense."""
           return lang.see.describe
   
   @beat(lang.see.perform_beat)  # <--- this
       def perform_as(self, the_actor: Actor) -> None:
           """Direct the Actor to make an observation."""
           if isinstance(self.question, Answerable):
               value: object = self.question.answered_by(the_actor)
           else:
               # must be a value instead of a question!
               value = self.question
               aside(lang.see.perform_aside_actual(value))  # <--- this

   👍React with 👍1Reacted by Sergio C. Orozco Torres