Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
support English keywords, i18N generation for Jython (excluding some languages) #197
This update adds support for English keywords, and includes auto-generation code for other languages. Languages that can not be normalized to be usable with ASCII are excluded from the autogeneration, as the current Jython support uses Python class names to support keywords (where Unicode is not supported).
This does not add support for using these languages yet, as I have not yet found a way to load these files from the PythonInterpretor used in JythonBackend correctly when imported from a step def file.
Thanks, I noticed that. It turns out that when the Python files are loaded, there is an issue with the i18N names that are not Ascii. While you can specify the encoding of a Python file at the top of the file (I use utf-8 of course, based on the Groovy output), it appears to only apply to String values, not class or variable names. As far as I can tell class names are limited to at least the Ascii subset. I've been looking through the Jython Backend code to come up with a way to support Given/When/Then/Etc. May need to use a dictionary to look-up these words, but still investigating. Once I figure that part out, I will add the import call to the step defs. Steve…
On Fri, Jan 27, 2012 at 4:38 PM, Aslak Hellesy < ***@***.*** > wrote: Looks nice. It would be nice if each stepdef script could import the DSL like this: ``` python import cucumber.runtime.jython.EN @Given('I have (\d+) "(.+)" in my belly') def something_in_the_belly(self, n, what): self.n = int(n) self.what = what ``` --- Reply to this email directly or view it on GitHub: e359d04#commitcomment-909826
I think java.text.Normalizer might do the trick - haven't tried it. It might not work for Chinese, Arabic, Hebrew etc - so maybe fall back to EN if a language's keywords can't be ASCIIfied?
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')
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')
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)
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.