I've taken a look through the strips documentation in regards to
localization and it seems as though it's pretty close to what's been
discussed already in this thread. The one thing stripes tries to do as
well is translate keys that could not be found into something a little
more user friendly (e.g. "fieldName" would be come "Field Name").
http://stripes.mc4j.org/confluence/display/stripes/Localization
David
Patrick Lightbody wrote:
This is really good stuff, keep working to flesh it out fully. Take a look at
the Stripes i18n/validation scopes for an example of a well-done implementation.
Also, one thing I'd note: we do default the value attribute to the evaluation
of the name attribute already, so the question is all about defaulting the i18n
key.
For the short term, you can actually achieve this by just editing your controlheader.ftl
template and making a call out to $stack.finValue("getText(...)"), but of
course we'd prefer to have best practices as the default option.
Fair enough. So if I understand correctly, before we
commit something
in this regard, you'd like to consider and come to
consensus on the
correct approach for standardizing the lookup of
label names when the
'key' shortcut is used within the tags.
With this in mind, I've taken a look at able and have
found that it does
not internationalize anything. Because of this:
1) the tags are not a verbose as I have found them to
be in most situations.
2) there's no 'best practice' we can leverage from
able.
So, does anybody else have any thoughts on what this
convention should
look like? Don, through your examples below
(ActionClass.name,
ActionClass.method.name, name, etc. . .), are you
proposing those
conventions as individual possibilities or a
hierarchy of which the
first one found would be applied. The latter seems
like a good idea to
me. . .except for the fact that I would reorder it
and define the
rule/convention as:
For any key 'example.propertyName' provided as a
shortcut to any of the
ui tags, the label should be displayed based upon the
first of the
following which can be resolved:
1)
getText('ActionClass.actionMapping.example.propertyNam
e')
2) getText('ActionClass.example.propertyName')
3) getText('example.propertyName')
4) 'example.propertyName'
Let me know your thoughts,
David
Don Brown wrote:
This is a tricky one and will take more thought.
Currently, the value
attribute is optional, but how the name is used for
the label key is the
question - ActionClass.name,
ActionClass.method.name, name, etc.
I'd like to see how the Able project will handle
this one, as they are
looking to work over Struts using a comprehensive
convention-based
approach.
Don
David H. DeWolf wrote:
Sounds good to me too. . .
any hope of convincing one of you to apply this
(or a similar) patch
prior to the release:
https://issues.apache.org/struts/browse/WW-1458
Thanks,
David
Don Brown wrote:
I want to roll the Struts 2.0.1 release next
weekend, October 8. A
lot of changes have gone into the code since
2.0.0 and I'd like to
have a solid release that people can check out
after Ted and my talks.
I'm thinking we'll do this at the Sunday
hackathon since I believe
Ted, Wendy, and I will all be present. Any
objections?
Don
------------------------------------------------------
---------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
------------------------------------------------------
---------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
------------------------------------------------------
---------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
------------------------------------------------------
---------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=44702&messageID=90791#90791
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
