If you're reading this, we've just migrated servers! If anything looks broken please email dion@thinkmoult.com :)
Translation of bimtester from IfcOpenShell
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
Tagged:
Comments
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 :)
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.
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:
German:
French:
I 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:
This is because of the substep call. This should not happen IMHO.
@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 ...
https://github.com/IfcOpenShell/IfcOpenShell/pull/1175/commits/6373ce4f06fe5fe186f14d2d87ea09f9df32c028
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.
Do yo mean the missing gettext?
The problem with gettext is ho to set the language in the code. I do not want the system language, The feature file defines the language, thus the assert method should be called with the language and inside this somehow the language needs to be passed for the otpt strings.
The same cold be set in the report. We cold get rid of the json translation files than.
In short I need a runtime language switch
it seams possible ... https://stackoverflow.com/q/37998300 and https://webpy.org/cookbook/runtime-language-switch
It should work but it does not :-(
https://github.com/berndhahnebach/gettexttest
running the program it should print the German translation no matter which language is set on the system.
but it prints:
I could get rid of the error, but it does not print the translation. :-(
I updated the repo.
It works :-)
Works great but what is needed to get no translation, means the pure string not translated?
A possibility would be to use language en and just copy the string in the po file, but this seams not smart IMHO.