Add multilanguage support to step definitions

[bartlangelaan]

🤔 What's changed?

This adds multilanguage support to step definitions. Fixes #117.

This means that you can now create an alias for step definitions, and use them.

For example, in JS you could write:

// helpers.js
export const Gegeven = Given;

// step.js
Gegeven('de homepage is open', () = {})

⚡️ What's your motivation?

Multilanguage support has already been added to the gherkin parser, which works fine. To make all sentences look right in code also, this is the missing piece of the puzzle.

🏷️ What kind of change is this?

• ⚡ New feature (non-breaking change which adds new behaviour)

♻️ Anything particular you want feedback on?

Some parsers are defined differently, so I tried to keep everything intact as much as possible. This means that the original casing is preserved.
If something should be changed, please let me know. I would love to see this functionality in the VSCode plugin!

📋 Checklist:

• I agree to respect and uphold the Cucumber Community Code of Conduct
• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• Users should know about my change
  • I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[kieran-ryan]

Nice solution @bartlangelaan - I like how it introduces a source of truth for defining keywords for matching step definitions.

Being conscious that aliases defined in the dialects may have been added without consideration for their equivalent use as function names, do you think there could be any unintended conflicts of extending from matching 3 keywords to 353?

For instance, if we look at Italian aliases for 'given'; 'Data' and 'Date' are common terms in software. Using these names could create matches for functions other than step definitions. Demonstrating an example with Python, using the @data decorator of the data package would detect strings passed to it as step definitions patterns:

@data('buf')
def parse_buffer(buf, magic_mode=False):
    return 'buf passed in as ' + repr(buf)

Steps containing buf would be considered defined:

Trying to consider the impact of supporting a wider array of matches e.g. could we see tools support specific dialects instead of the default? Though presently have no concrete thoughts on this.

Perhaps a safer middleground would be enabling configuration to use one of the dialects only at a time? Configuration was also proposed on #129. However would like to hear an additional viewpoint on that.

Solution may be fine, though these were the points that initially came to mind - interested to get your thoughts!

[luke-hill]

@michaelboyles what are your thoughts on this?

[michaelboyles]

I think the points made by Kieran are valid. This does seem to have the small potential to break things in small ways. I think probably unlikely in practice, but still

An alternative would be to have some directive at the top of the file. This mirrors how gherkin handles the language swapping.

// cucumber-lang: nl

Gegeven('de homepage is open', () = {})

The impl would then do a first pass to extract the language, then defineStepDefinitionQueries would become a function (naturalLanguage: string) => string[]