forked from cucumber/cucumber-jvm
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
steps toward Jython i18n support, still one hard-coded piece to remov…
…e, and some work around languages having unicode issues
- Loading branch information
Showing
4 changed files
with
34 additions
and
26 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
da476b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a decent workaround. Latin-to-ASCII able Locales get translated. Others don't because it's a limitation of Python/Jython.
Am I right?
da476b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct. To support the annotation format we're given by the Jython interpreter for these unicode, non-ascii-able languages, there will at least need to be some pre-processing phase on the file. One possibility for a future update: we could use a character replacement mechanism on both the I18N file generator and this pre-processing phase, creating classes whose names were ascii-able. For example, if in English we suddenly started spelling Given with the Yen sign (Gi¥en), and someone wrote the step def:
@gi¥en('I have (\d+) "(.+)" in my belly')
def something_in_the_belly(self, n, what):
self.n = int(n)
self.what = what
we could use a preprocess phase that parses this file, and feeds this to the Jython parser:
@GiU_00A5en('I have (\d+) "(.+)" in my belly')
def something_in_the_belly(self, n, what):
self.n = int(n)
self.what = what
This would run, grabbing the class name from the annotation, where the class def was already loaded in the EN.py I18N file:
And = But = GiU_00A5en = Then = When = I18NKeywordTemplate
(U+00A5 is Unicode char point for Yen sym)
Anyway, support for most of the languages is almost there - just need a way to load them and make them usable from any context (maven, cli, ide)
da476b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like it would allow people to write invalid python code. (non-ASCII annotations are invalid python as it seems).
Allowing people to write invalid python doesn't sound like a good idea to me. I think people working in non-ASCII languages should be forced to use ASCII.
da476b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm in agreement about keeping the Python code valid.