We added new 2Pack functionality, now it can import - export translations for whole Application Dictionary, also we fixed the problem with situation of AD_Element export. But I must warn you that we didn't try to implement 2Pack UNDO functionality, because we dont use this 2Pack feature. Of course Translation import-export is optional, you can enable - disable it.
Does the community need this feature?
Adempiere.lv Team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>We added new 2Pack functionality, now it can import - export translations for whole >Application Dictionary, also we fixed the problem with situation of AD_Element export. But I >must warn you that we didn't try to implement 2Pack UNDO functionality, because we dont use >this 2Pack feature. Of course Translation import-export is optional, you can enable - >disable it.
>
>Does the community need this feature?
Sure any contribution is welcome.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I expected that question Victor :), I agree that many people will not find that feature too much usefull. Standard import-export has only one weak moment it is using fixed IDs. I do not know how other developers is managing migrations between their own implementaions for their clients. Weakiest part of 2pack in my opinion is that it works great only on first time import. Maybe I spent too litle time to understand how UNDO works, but it never worked fine for me. We are working in this way:
1)We installed implementation for new client with 2Pack
2)After some time we added new functionality, patches, improvements, etc. so we need to run AD migration on that client.
3)We delete all AD with 'User maintained' entity type, and we run import from full 2Pack package for this client
So with this migration strategy we do not have possibility to use Original Import-Export routine, because developer and production databases have different AD_Sequence values.
PS
Described migration strategy is only in my head:), we will try it in soon future, In the past when I worked in other company I wrote Version Control System for Compiere Application dictionary with locks and full two-side synchronization possibilities betweeen databases, with repository and all, all, all. Migration looked like one click process, but these days are gone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand it issue I have same issue with Libero.
but I think we need solve it issue in Standard Functionality we need delete dependencies with ID in XML Translator and use same way that in 2Pack, it solve the issue in Standard Functionality
What do you think , can you contribute with improve ;-)?
kind regards
Victor Perez
www.e-evolution.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm afraid I don't have too much time to solve the problem that I almost solved in another way. Although I'm agree that your proposal sounds more useful for the end users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Standard import-export has only one weak moment
> it is using fixed IDs.
Good point!
I would like to see that addition in 2pack. +1 from my part.
I think the load of dictionary is being managed well in import translations.
But we still need a way to include i18n records for customizations and for migration scripts easily.
Centralizing customizations in 2pack is great.
In my Localizations Colombia package
to make it one click installation I needed to update all the translations manually via updates :-(
I created one universal Handler for all AD translations, it has tag <trl> and special attribute 'Parent Table Name'.
Each time when PackinHandler stops on this tag we go in CommonTranslationHandler where we have ParentTable name, and Parent record id (element.parent.recordid), then it's simple sql generation and execution. That is the main idea. Currently I'm stress testing it, it has some bugy moments (with defered elements), but the whole concept is working.
All AD handlers where modified only by a few lines
We added new 2Pack functionality, now it can import - export translations for whole Application Dictionary, also we fixed the problem with situation of AD_Element export. But I must warn you that we didn't try to implement 2Pack UNDO functionality, because we dont use this 2Pack feature. Of course Translation import-export is optional, you can enable - disable it.
Does the community need this feature?
Adempiere.lv Team
Hi Igor,
>We added new 2Pack functionality, now it can import - export translations for whole >Application Dictionary, also we fixed the problem with situation of AD_Element export. But I >must warn you that we didn't try to implement 2Pack UNDO functionality, because we dont use >this 2Pack feature. Of course Translation import-export is optional, you can enable - >disable it.
>
>Does the community need this feature?
Sure any contribution is welcome.
Kind regards,
Trifon
Hi Igor
I have a doubts what is the different the export and import translation with standard option to export and import.
Kind regards
Victor Perez
www.e-evolution.com
I expected that question Victor :), I agree that many people will not find that feature too much usefull. Standard import-export has only one weak moment it is using fixed IDs. I do not know how other developers is managing migrations between their own implementaions for their clients. Weakiest part of 2pack in my opinion is that it works great only on first time import. Maybe I spent too litle time to understand how UNDO works, but it never worked fine for me. We are working in this way:
1)We installed implementation for new client with 2Pack
2)After some time we added new functionality, patches, improvements, etc. so we need to run AD migration on that client.
3)We delete all AD with 'User maintained' entity type, and we run import from full 2Pack package for this client
So with this migration strategy we do not have possibility to use Original Import-Export routine, because developer and production databases have different AD_Sequence values.
PS
Described migration strategy is only in my head:), we will try it in soon future, In the past when I worked in other company I wrote Version Control System for Compiere Application dictionary with locks and full two-side synchronization possibilities betweeen databases, with repository and all, all, all. Migration looked like one click process, but these days are gone.
Hi Igor!
I understand it issue I have same issue with Libero.
but I think we need solve it issue in Standard Functionality we need delete dependencies with ID in XML Translator and use same way that in 2Pack, it solve the issue in Standard Functionality
What do you think , can you contribute with improve ;-)?
kind regards
Victor Perez
www.e-evolution.com
I'm afraid I don't have too much time to solve the problem that I almost solved in another way. Although I'm agree that your proposal sounds more useful for the end users.
> Standard import-export has only one weak moment
> it is using fixed IDs.
Good point!
I would like to see that addition in 2pack. +1 from my part.
I think the load of dictionary is being managed well in import translations.
But we still need a way to include i18n records for customizations and for migration scripts easily.
Centralizing customizations in 2pack is great.
In my Localizations Colombia package
to make it one click installation I needed to update all the translations manually via updates :-(
http://adempiere.svn.sourceforge.net/viewvc/adempiere/contributions/Localizations/Colombia/packages/LCO_Retenciones/dict/PackOut.xml?view=markup
starting from line 1277 ...
Great improvement! Thanks.
In fact
Regards,
Carlos Ruiz
> Does the community need this feature?
Sure Igor, I think this feature is good - can you please give us more details about the way you implemented it?
Regards,
Carlos Ruiz
I created one universal Handler for all AD translations, it has tag <trl> and special attribute 'Parent Table Name'.
Each time when PackinHandler stops on this tag we go in CommonTranslationHandler where we have ParentTable name, and Parent record id (element.parent.recordid), then it's simple sql generation and execution. That is the main idea. Currently I'm stress testing it, it has some bugy moments (with defered elements), but the whole concept is working.
All AD handlers where modified only by a few lines
document.startElement("", "", "field", atts);//OLD
PackOut packOut = (PackOut)ctx.get("PackOutProcess");//NEW
packOut.createTranslations(X_AD_Field.Table_Name, m_Field.get_ID(), document);//NEW
document.endElement("", "", "field");//OLD
contributed in request 1786994