Skip to content
This repository

[Feature Lang] Using different spoken languages #23

borisbrodski opened this Issue August 09, 2012 · 13 comments

3 participants

Boris Brodski Sebastian Benz Adrian Moya
Boris Brodski

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

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 !

Sebastian Benz

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.

Boris Brodski

I looks like possible. I do some tests right now. You could also look at:

Sebastian Benz
Boris Brodski

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...

Sebastian Benz
Boris Brodski

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.

Sebastian Benz
Adrian Moya

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...

Boris Brodski

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

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.

Sebastian Benz

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:

Boris Brodski 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 ""

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


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

--- (default, could be optional) -------------------------------

--- (keywords for all defined non-en languages) -------------------------------

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
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.

Sebastian Benz

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.