Details
Improvement
Resolved
Minor
Description
As proposed by Emerson Macedo on dev list, it would be useful to have keywords for different languages pre-configured.
An I18nKeywords that reads keywords from I18n resource bundles for different Locales should do the trick.
We can provide i18n bundles for the most common locales in our core jar (very small overhead in terms of size!), and users can add or override them as needed.
The localisation should be done when instantiating the Keywords class so it only happens once.
Activity
Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Description |
As proposed by Emerson Macedo on dev list, it would be useful to keywords for different languages pre-configured. An I18nKeywords that reads keywords from I18n resource bundles for different Locales should do the trick. |
As proposed by Emerson Macedo on dev list, it would be useful to have keywords for different languages pre-configured. An I18nKeywords that reads keywords from I18n resource bundles for different Locales should do the trick. We can provide i18n bundles for the most common locales in our core jar (very small overhead in terms of size!), and users can add or override them as needed. The localisation should be done when instantiating the Keywords class so it only happens once. |
I think we should still pursue the JDK-way, because the ResourceBundle is designed to handle resources by locale which I don't see YAML doing, and find a way to overcome the encoding limitation. E.g. this post points to one: http://www.kai-mai.com/node/128
In any case, in my opinion, of the two evils encoding is the lesser of the two: folks will not in general need to fiddle with the keywords bundles, and if they do it's a one-off thing to set the values of the keywords.
Mauro Talevi
added a comment - I think we should still pursue the JDK-way, because the ResourceBundle is designed to handle resources by locale which I don't see YAML doing, and find a way to overcome the encoding limitation. E.g. this post points to one: http://www.kai-mai.com/node/128
In any case, in my opinion, of the two evils encoding is the lesser of the two: folks will not in general need to fiddle with the keywords bundles, and if they do it's a one-off thing to set the values of the keywords.
Right. But I'm not sure we need resources by locale in this case. Considering it's internal for test purpose only, I think we need only one resource file, because we will have only one language per project, I think. Anyway, we can hack ResourceBundle as you mentioned and solve the problem. What do you think?
Emerson Macedo Leite
added a comment - Right. But I'm not sure we need resources by locale in this case. Considering it's internal for test purpose only, I think we need only one resource file, because we will have only one language per project, I think. Anyway, we can hack ResourceBundle as you mentioned and solve the problem. What do you think? But I'm thinking it makes sense to provide the keyword bundles for several locales, and not just for testing purposes.
Then users can simply instantiate new I18nKewords(Locale) and have all the keywords set for that locale.
Yes, let's provide our own version of ResourceBundle to overcome the encoding issue.
Mauro Talevi
added a comment - But I'm thinking it makes sense to provide the keyword bundles for several locales, and not just for testing purposes.
Then users can simply instantiate new I18nKewords(Locale) and have all the keywords set for that locale.
Yes, let's provide our own version of ResourceBundle to overcome the encoding issue.
Mauro Talevi
made changes -
| Assignee | Mauro Talevi [ maurotalevi ] |
Mauro Talevi
made changes -
| Status | Open [ 1 ] | In Progress [ 3 ] |
Added UTF8 support. See org.jbehave.scenario.i18n.I18nKeywordsBehaviour.
Mauro Talevi
added a comment - Added UTF8 support. See org.jbehave.scenario.i18n.I18nKeywordsBehaviour.
Added it_trader_is_alerted_of_status.scenario as example of fully i18n-ed scenario.
Mauro Talevi
added a comment - Added it_trader_is_alerted_of_status.scenario as example of fully i18n-ed scenario. Mauro Talevi
made changes -
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Removed i18n keyword bundles from core, apart from default en locale. Bundles should be provided separately and encoding issues should be addressed.
Updated behaviour and example to use different configurable locale and bundle.
Mauro Talevi
added a comment - Removed i18n keyword bundles from core, apart from default en locale. Bundles should be provided separately and encoding issues should be addressed.
Updated behaviour and example to use different configurable locale and bundle. Mauro Talevi
made changes -
| Component/s | Core [ 11086 ] |
About YAML, I've made my jar using it because only on Java 6 or early we
have possibility to set encoding of properties files. So, using Java 5 or
older, we need to use unicode code points to represent chars in some
languages because It assumes the file encoded with ISO 8859-1. In my
opinion, if people need to use code points, the scenario will not be so
readable. What do you think?