#4 "But I can't imagine the nightmare trying to support a system where every person looks the product name in a different language." - Carlos Ruiz
My scenario is as described in #21.
I think I have solved this and I'm willing to submit my work as a patch if there is any interest here to review it.
Please ask if anyone wants me to explain further.
Red1 help me to create this patch. You can find more information in README file. Find them all in the KenosTenantLanguage.zip.
If you need any assistance, please ask me.
Good Ricardo, I did a very quick review, it seems like it requires some extra work to make it integrable.
I like the fact that the change is very little and scoped, those are the solutions I prefer KISS principle
My visual peer review (not tested):
1 - on the migration scripts you need to replace the sequences with official sequences from iDempiere (just let me know if you need centralized ID credentials and I'll set up for you, or I can reserve some sequences if you prefer)
AD_Rule_ID=1120000 (although I think we don't need this one)
2 - Is I_W_AD_Table.java needed - I don't see a reference for that on code
3 - We need to generate model classes X_AD_Client and I_AD_Client
4 - I see you created a column AD_Table.IsSystemLanguage - but is not used, instead I think you missed the creation of AD_Client.IsAutoUpdateTrl
5 - I think we can integrate the beanshell rule directly in java code as this is planned to be official
Still haven't made tests so I cannot comment about potential issues with the approach.
Thanks Carlos for the quick review. Apologies for missing the MClient diff. I included that and uploaded as KenosTenantLanguage_v02.zip. (I pasted the MClient.diff at the bottom for your convenience of need not downloading the v02.zip.
The use of wrapper class is to avoid the use of GenerateModel classes (May not be good, so I will talk to Ricardo about it later).
The IsAutoUpdateTrl with <table>.isSystemLanguage() gives a fine-tuning control over which table we prefer to apply the Tenant language or not.
We will submit a v.0.3 later with the Centralised ID. I will ask Ricardo to apply for that from you.
diff -r a51e94aa5efd base/src/org/compiere/model/MClient.java
— a/base/src/org/compiere/model/MClient.java Mon Nov 14 21:04:30 2011 -0500
+++ b/base/src/org/compiere/model/MClient.java Wed Feb 08 17:02:41 2012 +0800
@@ -31,6 +31,7 @@
@@ -423,8 +424,15 @@
* @return true if automatically translated
public boolean isAutoUpdateTrl (String TableName)
- if (super.isMultiLingualDocument())
+ MTable t = MTable.get(Env.getCtx(), TableName);
+ Boolean sysLang = false;
+ if (t != null)
+ org.adempierelbr.wrapper.I_W_AD_Table twpr = POWrapper.create (t, org.adempierelbr.wrapper.I_W_AD_Table.class);
+ sysLang = twpr.isSystemLanguage();
+ if (super.isMultiLingualDocument() && !sysLang)
if (TableName == null)
Committed a different (but similar) approach.
We have now a process in System called Change Base Language - you can use this process to swap en_US to another base language of your preference, or if you want a system without base language just set it to a non-login language.
PO.updateTranslations and Synchronize Doc Translation were changed to synchronize any change on the master table (i.e. C_Charge) to the corresponding translation table (i.e. C_Charge_Trl) for the language selected by tenant.
Pending TODO: VerifyLanguageConfiguration process - as a helper for troubleshooting language problems
Potential-Idea -> Pending TODO: VerifyLanguageConfiguration