IDempiere/FullMeeting20130116

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2013-01-16

CarlosRuiz: Morning
nmicoud: Bonjour
Deepak: Namaste
a42niem: guten tag
hahmed: ahlan
JanThielemann: hallo
CarlosRuiz: will be reviewing here pull request from tbayen - but please feel free to open a topic for the meeting if you want
buildmaster: Project iDempiere build #670: SUCCESS in 8 min 35 sec: http://jenkins.idempiere.com/job/iDempiere/670/
buildmaster: globalqss: IDEMPIERE-530 improve performance to enable attachments and chat buttons
buildmaster: IDEMPIERE-554 Chat button broken
tbayen: Hi all. Nice to hear you review my contribution. Everythink ok with it?
CarlosRuiz: haven't arrived there yet :) got distracted reviewing the chat window
tbayen: ok. It's no big deal anyway.
buildmaster: Project iDempiere build #671: SUCCESS in 8 min 41 sec: http://jenkins.idempiere.com/job/iDempiere/671/
buildmaster: globalqss: IDEMPIERE-560 Chat window disappearing when moved
tbayen: Is anyone from non-english communities willing to discuss http://jira.idempiere.com/browse/IDEMPIERE-552 and the overall tranlsation and help system stuff behind it?
CarlosRuiz: centrally maintained off?
tbayen: ?
nmicoud: i think Compiere manages it using CtxArea
nmicoud: for each element, you define a main translation and one translation per context. Then you select a context per window
nmicoud: So, Organization could be translated by Org or Office or ...
tbayen: Is this a post-2006 compiere feature? Can't google it.
nmicoud: Business PArtner : Customer, Vendor, Employee...
nmicoud: it should have been introduced in 3.0.x version
CarlosRuiz: ctxarea is mostly for the SO/PO?
tbayen: We have some issues in german community where someone wants another translation than others. And some people need personalized texts for special reason. It would be nice to have a kind of layered system for that.
CarlosRuiz: but the centrally maintained would still solve what Thomas is describin?
CarlosRuiz: describing
nmicoud: http://www.compiere.com/downloads/release-notes/compiere-release-notes-04-10-08.pdf ; page 8
nmicoud: centrally maintained serves only to get the translation of the element in the correct context
tbayen: I think it would solve it if you turn centrally maintained off. I would like to do that. But I can't do it in a translation package. Before doing it world-wide I wanted to discuss it here.
nmicoud: You can have a "standard" translation, and then having specialized packages which only contains specialized translations
CarlosRuiz: so, you can create your own ctxareas / like a "custom" ?
nmicoud: yes
CarlosRuiz: that sounds better
nmicoud: but you have to add a lot of AD_XXX_CtxArea table
nmicoud: one for element, for window, tab, ...
nmicoud: it's quite massive
tbayen: I cant find it on page 8 :-(
nmicoud: search for compiere case number : 10017012
tbayen: Ah. got it. Thanks
tbayen: I would like to see more doc of that. But I don't think we need more tables for that. I want more flexibility in creating the translation. But if we created it it may be static.
nmicoud: i've also faced this and wanted to keep some translations without having all those tables. I've added a new table which store specific translation.
nmicoud: when i update translation, i overwrite some with those which are stored in this table
nmicoud: and then i launch the SyncTerminology
nmicoud: it's very basic but it does the job
nmicoud: if interested, i could make a quick documentation
tbayen: You could create a translation package "localnmicoud" and first apply the french and the the localnmicoud package. But we have no good tool chain to create the local package.
nmicoud: i do :) i can export those specific translation
nmicoud: using same process as Import/Export translation
tbayen: It's a bit the same with OSGi packages. They will need their own translation packages. So we could import "french", then "openBravoPOS-frech", then "localnmicoud".
tbayen: How do you export that?
nmicoud: same process as Import/Export translation => xml files
tbayen: Did you change the code for that?
nmicoud: yep
tbayen: Could not be hard. I will think about it.
nmicoud: 2 new forms (swing only) and others things i guess
nmicoud: i can prepare a quick doc and attach it on the ticket
nmicoud: that could give you idea
CarlosRuiz: sounds like my_trl_exceptions ? am I understanding right?
nmicoud: not aware of "my_trl_exceptions"
nmicoud: but yes, seems like that
CarlosRuiz: no / I mean
tbayen: Another tthought is that translations should be exchangeble fast and easy so that none does it alone. How about a central database server for this table.
CarlosRuiz: what you created is your own trl exceptions_
CarlosRuiz: ?
nmicoud: yes
CarlosRuiz: to keep them on a trl load
tbayen: Applying them to your translation tables is an own process you start after importing the standard translation?
nmicoud: import "standard" trl, then "specific/exception" ;
nmicoud: Exception overwrite standard ; and then SyncTerminology can be launched
a42niem: but sync termoinology is overwriting all with "centrally maintained". is it that what you want?
tbayen: What do you think about holding the exceptions on a central server (sorted through a package id) and using smart SQL to get exactly the combination you want?
nmicoud: yes because i have in my _trl table the exact translation i want so SyncTerminology is not a probleme
a42niem: ok
tbayen: a42niem, to set or unset "centrally maintained" from the translation package is another issue.
tbayen: There is at most one case in german where "central maintained" does not work. But I think for a good help system we need much more specialized text.
a42niem: which case?
tbayen: "rate" is used as "Wechselkurs" and as "Steuersatz". There is no common german word that describes both things.
a42niem: there is also "process" = "Prozess" or "verarbeiten"
tbayen: Steuersatz-window will be used not often so it is not a big matter. But it is not elegant.
a42niem: and i think we have some more
tbayen: Tranlation packages should be able to create new system elements and set/unset "centrally maintained".
CarlosRuiz: yep - and trl is dependent on ID actually which is useless for the non-official entries
CarlosRuiz: maybe we need to move it to be dependent on the uuid ?
tbayen: In feel like a deja vu. I read all that in the 2pack docs. :-)
tbayen: Is it easier to change translation import/export or to create a 2pack for translations?
red1: thats what i like to know too
a42niem: isnt it almost the same?
a42niem: hi red1
red1: Hi Dirk
red1: Carlos, your LCO Retenciones is ready
red1: as plugin with 2pack
red1: modelvalidator included
red1: i wonder if there be ID conflict if we have more plugins with 2Packs
tbayen: If we do this we will break the compatibility with old adempiere translations. Does that matter?
red1: i will test the 3 modules together - POS, Maintenance, LCO
buildmaster: Project iDempiere build #672: SUCCESS in 9 min 29 sec: http://jenkins.idempiere.com/job/iDempiere/672/
buildmaster: globalqss: IDEMPIERE-166 Rebranding of logo and product name
tbayen: nmicoud, do you know more about the compiere way with context areas? I would like to see over it before doing our own way.
nmicoud: i used them a little some years ago (when using compiere) ; will try to find more docs
nmicoud: have to answer a phone call, be back soon
buildmaster: Project iDempiere build #673: SUCCESS in 7 min 51 sec: http://jenkins.idempiere.com/job/iDempiere/673/
buildmaster: * Carlos Ruiz <carg67@gmail.com>: Merged in tbayen/idempiere (pull request #55: IDEMPIERE-539)
buildmaster: * tbayen: migration scripts with centralized ids
buildmaster: * tbayen: migration scripts for IDEMPIERE-539
buildmaster: * tbayen: Merge with bd14881f01d02cc8e4ea979e62c67b2c5373c0b4
buildmaster: * tbayen: IDEMPIERE-539 Import GL Window does not allow Key Values for Activity, Campaign, Sales Region
tbayen: What if we have a translation exceptions table that automatically synchronizes with a central repository server? To keep things up to date between different users?
CarlosRuiz: ready tbayen - IDEMPIERE-539 tested successfully - thanks a lot for contributing!
nmicoud: back
CarlosRuiz: I added a script to reorg the zk window
tbayen: :-) Thanks for helping me with the centralized ids.
nmicoud: tbayen : will search for some docs about CtxArea
nmicoud: CarlosRuiz: if you have time, can you please have a look at http://jira.idempiere.com/browse/IDEMPIERE-528
tbayen: I will do a proposal of the extended translations in the wiki. We should work on it together. MY thoughts are not yet clear.
CarlosRuiz: ah - I like that 528
CarlosRuiz: will discuss it today with Joel here - we were talking about that yesterday
nmicoud: it seems to work properly but a good deep review is needed, i think there are some hidden bugs
tbayen: for 528: Why not use a field for scripting code that can use Context Variables. This is used on many other oints in iDempiere?
tbayen: "Column, Operation, Search Key" sounds so static.
nmicoud: seems a good idea, wdyt Carlos ?
CarlosRuiz: nmicoud, and if the zoomcondition is empty it works as before?
nmicoud: yes, if nothing can be determined, it zoom on the 'default' window
CarlosRuiz: yep / context idea sounds good
CarlosRuiz: instead of creating a new window zoom condition we could also add it as a detail tab for Table
tbayen: I had a look to the parser Code for "Context Variable Scripts". When I remember right it is spread over the source tree and done more than one time. Perhaps you can axtract this a bit and do it only once. Later we could extend the scripting engine.
nmicoud: yep
buildmaster: Project iDempiere build #674: SUCCESS in 13 min: http://jenkins.idempiere.com/job/iDempiere/674/
buildmaster: globalqss: IDEMPIERE-539 Import GL Window / reorg zk window
tbayen: Ah, CarlosRuiz thanks for IDEMPIERE-539! I did not think about zk.
CarlosRuiz: yw
CarlosRuiz: guys - gtg - thanks a lot for attending the meeting
a42niem: tbayen: concerning context in compiere - it using is a new table called AD_CtxArea (Context Area) which is used in element, tab and window to relate a specific element
a42niem: and so a corresponding different translation if necessary
a42niem: i think the source code is no longer viewable online
a42niem: but you can download it from http://sourceforge.net/projects/compiere/files/Compiere/R3.3.0/ to have a look
tbayen: Sorry, I gtg. If you are interested in the translation issue please have a look at http://wiki.idempiere.org/wiki/Extended_Translations and _please_ write your own thoughts!
buildmaster: Project iDempiere build #675: SUCCESS in 7 min 30 sec: http://jenkins.idempiere.com/job/iDempiere/675/
buildmaster: globalqss: IDEMPIERE-555 Tenant user can edit System records when AutoCommit is disabled
CarlosRuiz: nmicoud, thought something additional - could you check if the user doesn't have permission for the zoomcondition window - then fallback to the default zoom window?
nmicoud: not tested, but it should work also. If evaluation doesn't succeed, the standard window is used. >But will test it anyway to confirm
buildmaster: Project iDempiere build #676: SUCCESS in 7 min 47 sec: http://jenkins.idempiere.com/job/iDempiere/676/
buildmaster: globalqss: IDEMPIERE-555 Tenant user can edit System records when AutoCommit is disabled / thanks to Heng Sin for catching this one