(moving this discussion of translation issues & the custommessages
module to the dev list in case others are interested)
Mike,
I agree with you & Mykola, that the target for Mykola's in-page
translation GSoC project would fitly nicely as an enhancement to the
custommessages module – i.e., leveraging the existing functionality to
store customized messages in the database and introduce the ability to
make those customizations directly within the pages of the web
application.
Since we are storing messages in the database, the need to distinguish
module-specific keys from core keys is less of an issue. Originally,
we were imagining updating the message bundles, which means that we
would need to know which properties file (and where it was) to update
it. Changing to a read-only mode (where Spring messaging handles
getting the right message from the right module or core properties
file) and our writes all go to the database, makes this issue moot… at
least until we get to exporting, where it would be nice to export
messages in a format that could easily be used to update/replace
properties files within core or module(s).
There are several reasons for creating an openmrs:message tag to
replace use of the spring:message tag. Here are the main ones:
* Provide built-in support for our in-page translation mode (tag
will render a special span tag when translation mode is turned
on… something like this
<http://jsfiddle.net/burke/QZRJL/embedded/result/>)
* Allow default messages to be supplied in place without having to
escape HTML entities
* Allow the locale for the default message to be specified (so the
default message does not /have/ to be in the en locale)
Cheers,
-Burke
On Thu, May 17, 2012 at 4:37 AM, Mykola Vorobey
<vorobeymyk...@gmail.com <mailto:vorobeymyk...@gmail.com>> wrote:
Hi, Mike,
* Not sure what you mean by "support for other modules,
ability to distinguish between core and module
messages". The custommessages module stores all of it's
custom translations, whether for a core-provided message
or a module-provided message in the same table already.
Is there something that is missing that you would need
to add in here?
Actually, the the distinguishing between affiliation of any
message to certain module or core must be performed on basis of
module naming conventions. And if conventions are not followed,
then the decision must be done using special attribute of
/openmrs:message/ tag, that overrides message inference.
* Export functionality - just so you are aware,
custommessages already has some capabilities to export
messages. I'd be happy to see enhancements to this, but
curious as to what you have in mind.
I meant adding of ability for user to export all in-place edits,
that made (or updated, or both) by him using this module.
* I think a new openmrs:message tag is a great idea, and
in general I think we would have done better by wrapping
all of the tags we use in corresponding openmrs tags to
give us the ability to customize these as needed. That
being said, the spring:message tag already supports a
default translation - I believe you use the "text"
attribute of the tag. Is this what you are referring
to, or were other capabilities needed here?
Not exactly, we just wanted to have default text as tag body,
because Burke was a bit concerned of need to escape HTML specific
entities &, ", <, and >, when using "text" attribute. In the rest,
I do believe, that we understand each other right.
Thanks, for discussion! I would like to know if anyone of CCs has
opinion on on this, so we can review any outstanding questions as
well?
Best,
Mykola
On Thu, May 17, 2012 at 10:28 AM, Michael Seaton <msea...@pih.org
<mailto:msea...@pih.org>> wrote:
Hi Mykola,
This sounds good to me - I'd value these great additions to
custommessages. A few minor comments:
* Not sure what you mean by "support for other modules,
ability to distinguish between core and module
messages". The custommessages module stores all of it's
custom translations, whether for a core-provided message
or a module-provided message in the same table already.
Is there something that is missing that you would need
to add in here?
* Export functionality - just so you are aware,
custommessages already has some capabilities to export
messages. I'd be happy to see enhancements to this, but
curious as to what you have in mind.
* I think a new openmrs:message tag is a great idea, and
in general I think we would have done better by wrapping
all of the tags we use in corresponding openmrs tags to
give us the ability to customize these as needed. That
being said, the spring:message tag already supports a
default translation - I believe you use the "text"
attribute of the tag. Is this what you are referring
to, or were other capabilities needed here?
Adding in these features to custommessages, mavenizing the
module, etc is fine with me. I'm excited to see it evolve!
Cheers,
Mike
On 05/17/2012 03:13 AM, Mykola Vorobey wrote:
Thanks, Mike, for so wide response.
Yes, you are right, that it would be just kind of alternative
UI built on top of your module. We are planning to do a bunch
of work on this actually inside /custommessages/module
project. It will actually include introducing of:
* new mode for rendering OpenMRS pages with text
messages, that can be translated in-line -
i.e./translate mode/
* functionality that allows user to toggle translate mode
on/off.
* corresponding /Global Property/ for handling this mode
* adding new extension point within core
/footerFull.jsp/ for placing toggling button into and
implementing this inside module
* new access privilege for managing translations
* ability to edit “translatable” messages in place
(actually, it would be a kind of javascript engine)
* DWR translation service to be used for handling
outcomes of in-place editing
* support for other modules, ability to distinguish
between core and module messages, so it would require
some changes into service and data access tiers in
order to handle modules messages persisting alongside
with core ones
* enhanced export functionality (i.e. add ability for
user to export translations, which he has already done
so far)
* may be some enhancements with project codebase, i.e.
mavenize it, etc
Alongside with this, we are going to add into core new
/openmrs:message/ tag with corresponding /OpenmrsMessageTag
/class, which wraps existing spring:message tag and
adds ability to put default translation within tag body.
Thereafter we need to provide translation capability for
/OpenmrsMessageTag/ class within project module. So, this is
quite convenient to have such thing as "message code mode",
so we can develop this idea further in order to suit our
needs in this stuff.
I would definitely like to know your opinion about
possibility and technical details of adding above mentioned
features into /custommessages/ project. So, please, share
your feedback on this, we appreciate it.
Cheers,
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
