Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[Feature Lang] Using different spoken languages #23

Open
borisbrodski opened this Issue Aug 9, 2012 · 13 comments

Comments

Projects
None yet
3 participants
Collaborator

borisbrodski commented Aug 9, 2012

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 !

Owner

sebastianbenz commented Aug 10, 2012

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.

Collaborator

borisbrodski commented Aug 14, 2012

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

Owner

sebastianbenz commented Aug 14, 2012

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/bmwcarit/Jnario/issues/23#issuecomment-7718447.

Collaborator

borisbrodski commented Sep 24, 2012

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

Owner

sebastianbenz commented Sep 24, 2012

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.

Collaborator

borisbrodski commented Sep 24, 2012

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.

Owner

sebastianbenz commented Sep 24, 2012

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.

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

Collaborator

borisbrodski commented Nov 7, 2012

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

Owner

sebastianbenz commented Nov 7, 2012

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

Collaborator

borisbrodski commented Nov 7, 2012

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.

Collaborator

borisbrodski commented Nov 14, 2012

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

Owner

sebastianbenz commented Nov 17, 2012

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?

@ghaith ghaith pushed a commit to ghaith/Jnario that referenced this issue Jun 29, 2017

@riederm riederm Merge pull request #18 from ghaith/fix_richstring_tests
Issue #23 Fix richstring tests
660a381
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment