Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add multilanguage support to step definitions #153

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bartlangelaan
Copy link

@bartlangelaan bartlangelaan commented Nov 5, 2023

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

@bartlangelaan bartlangelaan marked this pull request as ready for review November 5, 2023 14:28
Copy link
Sponsor Member

@kieran-ryan kieran-ryan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

image

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!

@kieran-ryan kieran-ryan added the ⚡ enhancement Request for new functionality label Jan 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⚡ enhancement Request for new functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support localized java annotations
2 participants