I am interested in translating bimtester into German and French. Translating the report (the html template) is simple. But I would like to see the feature files and the assert strings translated too. The assert strings should be possible too, but the step definitions I do not know of. Does behave support this? Do we have a possibility to do that? I do not really have a idea where to start, but I would spend time on this if I would know how it works.
cheers bernd
Ich kann helfen.. si on me dit ce que je dois faire. I can translate txt files..
Lukas
I can translate to Dutch. How can I help?
@bernd you can call steps from other steps.
Because each MicroMVD is self-contained in each file, just create a new step for each translation, and call the English version of the step, which may be the "master".
@Meetlat awesome! Maybe once @bernd works it out you can help fill in Dutch :)
@Moult said:
@bernd you can call steps from other steps.
Because each MicroMVD is self-contained in each file, just create a new step for each translation, and call the English version of the step, which may be the "master".
this is what I found too. IMHO this should be possible much smarter. But ATM I do not have an idea how and not the time to implement somthing complex. Thus I will go for this.
For the report I propose to use a tag. At the beginn of a german feature file should be a @lang=DE_de This tag will be in the json report. With this informatin it will be possible to choose the correct report template on html report generation. This would mean one feature one language what makes sense IMHO.
Finally the assert strings. How about them? How do we get them translated?
I've added the IfcOpenShell tag, and to the name.
Found that Gherkin language does support different native languages :-) https://cucumber.io/docs/gherkin/languages/
@bernd yes, Gherkin does, which is good for the top level keywords like "Feature" or "Scenario", but for each individual step the prefix we use in MicroMVDs is "* " (i.e. the bullet point) since unlike programming usecases, there isn't much of a "Given, When, Then" semantic.
sure, I am aware about the "*" workflow we use. BTW the bullet point is needed if another step is called.
Translation works great so far. I may update the template too. Means I would add more templates for more languages Only a few words are in the template but it just looks better if all is in the choosen language.
@bernd said:
For the report I propose to use a tag. At the beginn of a german feature file should be a @lang=DE_de
This is not needed at all. Gherkin has code words to set the language. For German
# language: de
started the translation ... Here we are https://github.com/IfcOpenShell/IfcOpenShell/pull/1171
Since I have no idea how to use a translation system for the html template texts, I replaced them by variables and used json to load them.
Damn, just realized some problem I am not able to fix ...
If a translated step fails I get an error message but everything works well ... I have no idea how to get rid of this error message.
English:
IFC data must use the IFC2X3 schema
Assertion Failed: We expected a schema of IFC2X3 but instead got IFC4German:
Die IFC Daten müssen das IFC2X3 Schema benutzen
Assertion Failed: FAILED SUB-STEP: * IFC data must use the IFC2X3 schema
Substep info: Assertion Failed: We expected a schema of IFC2X3 but instead got IFC4
Traceback (of failed substep):
File "/usr/local/lib/python3.7/dist-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python3.7/dist-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "../../tmp/bimtesterfc/features/steps/ifcdata.py", line 17, in step_impl
schema, IfcFile.get().schemaFrench:
Les données IFC doivent utiliser le schéma IFC2X3
Assertion Failed: FAILED SUB-STEP: * IFC data must use the IFC2X3 schema
Substep info: Assertion Failed: We expected a schema of IFC2X3 but instead got IFC4
Traceback (of failed substep):
File "/usr/local/lib/python3.7/dist-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python3.7/dist-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "../../tmp/bimtesterfc/features/steps/ifcdata.py", line 17, in step_impl
schema, IfcFile.get().schemaI think the assertion failures need to be translated too. Use gettext I guess?
I will have a look at gettext.
But the error should not arise on a substep no matter if translated or not.
@bernd what do you mean? The error is expected - it wants IFC2X3 but you provided an IFC4 file.
the error in English is expected. But this is not expected IMHO:
Substep info: Assertion Failed: We expected a schema of IFC2X3 but instead got IFC4
Traceback (of failed substep):
File "/usr/local/lib/python3.7/dist-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python3.7/dist-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "../../tmp/bimtesterfc/features/steps/ifcdata.py", line 17, in step_impl
schema, IfcFile.get().schemaThis is because of the substep call. This should not happen IMHO.
@bernd maybe it should catch and then rethrow failed substep assertions?
@Moult said:
@bernd maybe it should catch and then rethrow failed substep assertions?
how should this work?
in short, I would like to suppress the trace back of the failed substep, as it is done for any normal failed step
a try: except: might work but I need to save some variables in the context than to make a good looking output. I will give it a try ...
@bernd said:
a try: except: might work but I need to save some variables in the context than to make a good looking output. I will give it a try ...
@bernd said:
@bernd said:
a try: except: might work but I need to save some variables in the context than to make a good looking output. I will give it a try ...
It is much better, but I am not 100 % happy with this either as the assert is evalutaed twice. First the english one if this fails an AssertionError is raised which will be catched by the Exception. Afterwards the assert from the other language is evaluated and the "real" AssertionError is raised.
@bernd I'm also unhappy with this implementation. I think a better solution would be for the assert to call a function which will return the translated string. See gettext.
like this ?
https://gitlab.com/bimtester/bimtesterfc/-/commit/f2b3038a1d0b
Looks incomplete but moving in the right direction.
Login or Register to reply.