Hmm… I struggled with that in initial designs. I think we might be possible to maybe created some kind of i18n marker to a resource or something ? The problem is that (for the moment) we haven’t addressed any i18n stuff in the spec, so we’ll have to see how we can handle that (although for the moment condition types are not really a part of it either).
If we provide the possibility for condition types to be internationalized, we’ll have to also think about automated / manual translation, as very often it is not the same people doing the condition type design and the UI translation. So maybe we would need some kind of system that would work with resources and uses OSGi fragments to deploy translations ? cheers, Serge… > On 13 avr. 2016, at 14:57, Thomas Draier <[email protected]> wrote: > > Ok, > Working on this task, I have the issue that I cannot have > "internationalized" data in stored items (yet), but right now condition > types do have translation for names/descriptions handled by resource > bundles. So - either we drop the support for any translation inside Unomi > and let all clients handle that somehow, or we add an (optional) attribute > for names/description per language in the metadata object. In my opinion it > would make more sense to handle that on unomi side, as any end user can > create new condition types - it would be nice if he's able to store > translations for the items he creates. Any opinion ? > > > On Wed, Apr 13, 2016 at 1:30 PM Thomas Draier <[email protected]> wrote: > >> Ok, I'll create a ticket and start working on that. >> >> thomas >> >> >> On Sat, Apr 9, 2016 at 9:18 PM Jean-Baptiste Onofré <[email protected]> >> wrote: >> >>> +1 >>> >>> It sounds good to me. >>> >>> Regards >>> JB >>> >>> On 04/08/2016 11:39 AM, Thomas Draier wrote: >>>> Hi, >>>> >>>> I was thinking of some possible improvements on the condition types, to >>>> make them more flexible. >>>> Currently, condition types are defined in unomi plugins - they are read >>>> from a json inside a plugin bundle, and then loaded into memory. Some of >>>> the base conditions rely on actual java code, so it make sense to put >>> them >>>> into a bundle - but other some other conditions are only simple >>> combination >>>> of other conditions, and are usually very specific to a domain. An end >>> user >>>> may want to create his own condition using simple JSON definition, and >>> may >>>> not want to develop and deploy a bundle just for that. It would be nice >>> to >>>> be able to add new condition types by simply using REST API. >>>> If you look at the pageViewEventCondition - it is only based on simple >>>> boolean and property conditions, and is very specific to the type of >>> events >>>> that will be sent by a third party server. They should get out of >>> default >>>> unomi installation, and rather be created directly by the server that >>> will >>>> send these events. >>>> Allowing to create/edit conditions will of course require to persist >>> them, >>>> and so require some changes in the ConditionType object, changing from >>>> "PluginType" to "Item", and the way they are read by the definitions >>>> service. >>>> What do you think ? >>>> thomas >>>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>
