The 'steps' method does not allow using another language

[manuca]

Original Lighthouse Ticket 668

I'm not sure if this issue is related to Cucumber or Gherkin, please let me know, the original bug was related to the former.

My Gemfile.lock contains
cucumber (1.1.0)
builder (>= 2.1.2)
diff-lcs (>= 1.1.2)
gherkin (~> 2.5.0)
json (>= 1.4.6)
term-ansicolor (>= 1.0.6)

I want to reuse the following step that runs ok with language set as 'es' on the header.

Dado que importo un CSV para el modelo "test_csv" con:
"""
"col1","col2","col3","col4",1,2
"col1","col2","col3","col4",1,2
"""

In my steps file I have

Dado /^que se reutiliza un escenario$/ do
  steps(<<-'eos'
    Dado que importo un CSV para el modelo "test_csv" con:
    """
    "col1","col2","col3","col4",1,2
    "col1","col2","col3","col4",1,2
    """
    eos
  )
end

But I get Lexing error on line 1: ' Dado que ...

The problem is solved if I write:

Dado /^que se reutiliza un step$/ do
  steps(<<-'eos'
    Given que importo un CSV para el modelo "test_csv" con:
    """
    "col1","col2","col3","col4",1,2
    "col1","col2","col3","col4",1,2
    """
    eos
  )
end

Please note that to solve the issue I have to use the english keywords while passing the step to the steps method.

[ghnatiuk]

The issue here is a combination of things between Gherkin and Cucumber...

Gherkin doesn't have a convenient way to parse steps like this with any language other than English, unfortunately, and doesn't allow specification of language via a pragma like features does.

If that were to be changed (simply allowing comments within #steps( ... ) text)
there would be a few ways of continuing on. The simplest for cucumber (no change at all) would to require you to specify non-English languages within the steps text like so:

 Dado /^que se reutiliza un step$/ do
  steps(<<-'eos'
    # language: es
    Dado que importo un CSV para el modelo "test_csv" con:
    """
    "col1","col2","col3","col4",1,2
    "col1","col2","col3","col4",1,2
    """
    eos
  )
end

but this seems a bit silly since we already (obviously) knows what language we're using for the steps file at this point. It seems reasonable to me that we would want to infer the current language for parsing steps from the language being used for the containing step itself. That could cause some minor breakage for existing non-english writing cukers.

[mattwynne]

Interesting. We need to fix this before we release #68

[ghnatiuk]

I misspoke...we know which language the feature was written in when these steps are called, not what language the step name is. Inferring which language to parse within #steps would couple the step definitions to features in a way that they aren't currently. Is it terribly English-centric of me to want to require the language pragma after all?

[mattwynne]

On 29 Sep 2011, at 01:07, Gregory Hnatiuk wrote:

I misspoke...we know which language the feature was written in when these steps are called, not what language the step name is. Inferring which language to parse within #steps would couple the step definitions to features in a way that they aren't currently. Is it terribly English-centric of me to want to require the language pragma after all?

I think it would be friendlier to the user if we can infer the default language of the Gherkin being passed into #steps from the language of the feature file where the step was matched. It seems like passing the spoken language of the reader down to the step definition wouldn't necessarily have to add much coupling, would it?

[ghnatiuk]

Well, it would prevent you from being able to use nested steps written in another language (e.g. copied in from another project/ a step definition library gem, etc..) . Maybe not a huge deal.

[mattwynne]

@ghnatiuk I see what you mean. So I think we should default to the language that the matched step was written in, but allow you to override it, either in the way you suggested or by passing a language ID as another argument to the #steps method itself.

[scriptfans]

How to solve this problem? I wanna use chinese in the nested steps.

[mattwynne]

@scriptfans I would suggest you work around this by extracting methods from the steps you want to nest, then calling those methods directly instead of calling #steps. Right now, unless we get a patch, this isn't going to get fixed any time soon, I'm afraid.

[viniciusgati]

i think i have this issue, this is still open?

[amencarini]

I also think I got into this issue; could you please confirm if this is still open?

[mattwynne]

Yes, it has not been resolved.

[mattwynne]

I think that change in Gherkin, once released, will allow us to do this now.

[amencarini]

Too bad my active projects are all built around English features and I can't take advantage of this :D
Thanks @mattwynne!

[mattwynne]

Fixed by #433.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.