[Feature Lang] Using different spoken languages

[borisbrodski]

With cucumber it is possible to use different spoken languages within feature definitions:

https://github.com/cucumber/cucumber/wiki/Spoken-languages

It would be great, if Jnario had the same feature too. I think, that the solution with the '# language: XX' first line comment would be convenient way to do this.

Thank you for the great tool !

[sebastianbenz]

Thanks for the suggestion. I also would like to have this feature, but I am not sure yet how to implement it. The easiest thing would probably be to make the lexer configurable at runtime, but I don't know whether that's possible with the generated ANTLR lexer.

[borisbrodski]

I looks like possible. I do some tests right now. You could also look at: http://www.eclipse.org/forums/index.php/m/901545/

[sebastianbenz]

That would probably be the easiest solution if we could implement it by
overriding the generated lexer. I am currently on vacation so I don't
really have time to look into it. Thanks for your help!

Am 14.08.2012 um 08:35 schrieb Boris Brodski notifications@github.com:

I looks like possible. I do some tests right now. You could also look at:
http://www.eclipse.org/forums/index.php/m/901545/

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/23#issuecomment-7718447.

[borisbrodski]

I managed to override a simple keyword within the main parser and the ui-parser. The problem I stuck with is the auto completion. As you can imagine, the original (english) keyword still get shown...

[sebastianbenz]

This is great news! The keywords are currently hardcoded in the proposal provider. Could this be the cause of your problem?

On Sep 24, 2012, at 4:29 PM, Boris Brodski wrote:

I managed to override a simple keyword within the main parser and the ui-parser. The problem I stuck with is the auto completion. As you can imagine, the original (english) keyword still get shown...

—
Reply to this email directly or view it on GitHub.

[borisbrodski]

I experimented with my own small project. The terminals you defined in Jnario are tricky. But I'm sure, if I get it with my test project, I will get it with the Jnario also.

I should probably push it to the github.

[sebastianbenz]

I still wouldn't consider the code completion to be a limiting factor, as we had to override the proposals for steps in Jnario anyway. This could be easily adapted to support "generic" keywords.

On Sep 24, 2012, at 4:37 PM, Boris Brodski wrote:

I experimented with my own small project. The terminals you defined in Jnario are tricky. But I'm sure, if I get it with my test project, I will get it with the Jnario also.

—
Reply to this email directly or view it on GitHub.

[adrianmoya]

Hey guys, I've just discovered Jnario 2 minutes ago and I'm pretty excited about it! (I come from Behat/PHPSpec from the PHP world, looking for alternatives for a new java project) Browsing the issues in github I came with this one. Does this means Jnario doesn't support other languages than english for expressing features? That would be a show-stopper for me. :(
I may contribute with spanish translations files if you guys can put everything in place...

[borisbrodski]

@adrianmoya
Thank you for the offer!
We are on it :-)

@sebastianbenz
After couple of experiments I must admit, that I can't proper modify lexer extends from it. The problem is, that the terminals we are looking for (e.g. Given, Then) are complex ones (using -> ). For example:

var Given=1 // ok
var Given = 1 // ERROR

In order to translate those terminals we actually need to generate a new lexer for each language.
I work on a feature request for the Xtext.

If you want, we could discuss this matter over the phone (this is the quickest way, I think). Just let me know and I send my phone number over the private twitter message.

[sebastianbenz]

Currently I think that implementing a generator that generates all language specific lexers is the best idea. The generator could read the generated lexer(s) and replace the Given, When, Then keywords with their respective translations. The whole process could be integrated into the normal feature workflow. Btw we could use the cucumber language definition as input for the generator:

https://github.com/cucumber/gherkin/blob/master/lib/gherkin/i18n.json

[borisbrodski]

https://github.com/cucumber/gherkin/blob/master/lib/gherkin/i18n.json looks very good.

So, here is my idea. We can't just copy the Lexer and replace all "Given" by "Angenommen". The problem is, that those keywords are integrated into the complex decision tables (especially in case of Jnario with the complex terminal). What we need to do is to enhance Xtext. For example:

--- example.xtext -------------------------------
grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals
generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"

languages "en", "de"; // Define languages available

Model:
greetings+=Greeting*;

Greeting:
"%{hello}" name=ID '!'; // Use %{NAME} placeholder within the grammar

--- example.properties (default, could be optional) -------------------------------
hello=Hello

--- example-de.properties (keywords for all defined non-en languages) -------------------------------
hello=Hallo

The Xtext generator has to be extended with a pre-processing step:

for language : languages
read property-file for 'language' (fall back to default, if keywords are missing)
replace all %{} placeholders with the translated keywords
run ANTLR
rename Lexer to the Lexer_language
end for

Add new interface:

interface ILocaleProvider {
String determineLocale(Resource resource, ...);
}

Then if languages.size>1 bind Lexer to LexerDelegator, that calls the determineLocale() and pass all calls to the right lexer.

The potential problem:
All keywords has intern names. Those names should not depend upon selected language.
If you take a look of the formatter, you reference keywords per names there. The translated keyword
should keep the English names.

[borisbrodski]

I posted a proposal draft here: http://www.eclipse.org/forums/index.php/t/439313/

[sebastianbenz]

After the discussion I would also say that adding such a feature wouldn't make much sense for xtext, as the use case is usually not that relevant. Furthermore, adding such a feature to Xtext would require a lot of work and would make a lot of things unnecessarily complicated. But Hendrik's suggestion sounds reasonable good and would be worth a try. What do you think?