Use of other spoken languages about vscode

[tulavalle]

Thanks for your contributions @HDelpr and @tulavalle in raising - have added some initial documentation on gherkin localisation to the README arising from your issues. 🙌

This would be a SpecFlow deviation rather than Cucumber.

An initial observation is that the Cucumber localisation documentation was copied over to SpecFlow documentation without the necessary information to indicate incompatibilities; SpecFlow dialects documentation states:

Note Big parts of this page where taken over from https://cucumber.io/docs/gherkin/reference/.

The Cucumber ecosystem (including this extension) adhere to the keys for spoken languages in the Cucumber gherkin parser repository - which the localisation documentation is created from. Note, it does not contain an nl-NL, en-US or pt-BR key. For example, using the nl key specified in the localisation documentation will work for you:

# language: nl
Functionaliteit: Rekenmachine

  @mytag
  Scenario: twee getallen optellen
    Stel I have an "expression"
    En het tweede getal 70 is
    Als de twee getallen opgeteld zijn
    Dan is het resultaat 120

In the SpecFlow Configuration Elements documentation, building on the aforementioned gherkin localisation documentation, they "recommend using specific culture names (e.g.: “en-US”) rather than generic (neutral) cultures (e.g.: “en”)" - this appears to be driven by how SpecFlow is implemented. This SpecFlow deviation is not supported by the gherkin parser and will raise a parsing error, see below example:

from gherkin.parser import Parser
from gherkin.pickles.compiler import Compiler

parser = Parser()
gherkin_document = parser.parse(
"""
# language: nl-NL
Functionaliteit: Rekenmachine
"""
)
pickles = Compiler().compile(gherkin_document)

...
gherkin.errors.CompositeParserException: Parser errors:
(2:1): Language not supported: nl-NL

Actions

Considering the extension supports the gherkin spoken languages localisation, I have closed the issue. However I was wondering @HDelpr/@tulavalle whether you can advise if not following the 'recommendation' of SpecFlow of using 'specific culture names' has any impact on your SpecFlow testing i.e. using the global names such as en, nl and pt? If no issue, the extension should be compatible with your gherkin and also with SpecFlow testing by using those keys.

Otherwise, I would suggest to open an issue with SpecFlow to support the keys from the gherkin localisation documentation; or alternatively to raise an issue on the gherkin parser repository to support additional specific culture keys.

Hope this provides some clarity, but please comment if any queries, etc. There is definitely scope to improve documentation on this topic for both Cucumber and SpecFlow so interested in any thoughts. Cheers!

The added documentation regarding the required settings helped resolve the issue. All you had to do was apply them in settings.json. As I use Specflow, the language configuration was being done by specflow.json. After configuration, for the extension to identify the feature files, it was enough to include the language indication in each file "*.feature. In the case of Brazilian Portuguese, specifying (pt-BR) does not work, however, leaving it generic I was able to use the extension without problems: "# language: pt". Another one did it, thanks for your attention @kieran-ryan!

[kieran-ryan]

Thanks for your contributions @HDelpr and @tulavalle in raising - have added some initial documentation on gherkin localisation to the README arising from your issues. 🙌

This would be a SpecFlow deviation rather than Cucumber.

An initial observation is that the Cucumber localisation documentation was copied over to SpecFlow documentation without the necessary information to indicate incompatibilities; SpecFlow dialects documentation states:

Note Big parts of this page where taken over from https://cucumber.io/docs/gherkin/reference/.

The Cucumber ecosystem (including this extension) adhere to the keys for spoken languages in the Cucumber gherkin parser repository - which the localisation documentation is created from. Note, it does not contain an nl-NL, en-US or pt-BR key. For example, using the nl key specified in the localisation documentation will work for you:

# language: nl
Functionaliteit: Rekenmachine

  @mytag
  Scenario: twee getallen optellen
    Stel I have an "expression"
    En het tweede getal 70 is
    Als de twee getallen opgeteld zijn
    Dan is het resultaat 120

In the SpecFlow Configuration Elements documentation, building on the aforementioned gherkin localisation documentation, they "recommend using specific culture names (e.g.: “en-US”) rather than generic (neutral) cultures (e.g.: “en”)" - this appears to be driven by how SpecFlow is implemented. This SpecFlow deviation is not supported by the gherkin parser and will raise a parsing error, see below example:

from gherkin.parser import Parser
from gherkin.pickles.compiler import Compiler

parser = Parser()
gherkin_document = parser.parse(
"""
# language: nl-NL
Functionaliteit: Rekenmachine
"""
)
pickles = Compiler().compile(gherkin_document)

...
gherkin.errors.CompositeParserException: Parser errors:
(2:1): Language not supported: nl-NL

Actions

Considering the extension supports the gherkin spoken languages localisation, I have closed the issue. However I was wondering @HDelpr/@tulavalle whether you can advise if not following the 'recommendation' of SpecFlow of using 'specific culture names' has any impact on your SpecFlow testing i.e. using the global names such as en, nl and pt? If no issue, the extension should be compatible with your gherkin and also with SpecFlow testing by using those keys.

Otherwise, I would suggest to open an issue with SpecFlow to support the keys from the gherkin localisation documentation; or alternatively to raise an issue on the gherkin parser repository to support additional specific culture keys.

Hope this provides some clarity, but please comment if any queries, etc. There is definitely scope to improve documentation on this topic for both Cucumber and SpecFlow so interested in any thoughts. Cheers!

[kieran-ryan]

Thanks for the valuable feedback @tulavalle! If you encounter further issues or have any feature request ideas while using the extension, feel free to raise and we'll take a look. Thanks! 🙌