|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|feature request||[Openbravo ERP] A. Platform||major||always||2009-01-31 15:36||2009-05-22 19:33|
|Priority||normal||Resolution||open||Fixed in Version|
|Status||acknowledged||Fix in branch||Fixed in SCM revision|
|OS Version||Database version||Ant version|
|Product Version||2.40MP1||SCM revision|
|Review Assigned To|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0007301: Verify translations translates also user data, not just the application
|Description||Only common nouns may be translated automatically, translating proper nouns such as product names causes more harm as the translations need to be maintained even if there is no intention to translate them.|
This causes confusion when the application is multilingual, but for example product names are not translated. When a product name is modified the old name is still used for other than the system language.
At least product and account element translations should not be automtic.
|Proposed Solution||Remove automagic translations for user data.|
|Attached Files||no-translations-for-user-data-12582.diff [^] (2,124 bytes) 2009-01-31 15:36 [Show Content]|
|Rafa: let's discuss this carefully as part of triage. I am not convinced this is a defect.|
|Paolo, could you give an example why the product name translation should be copied automatically?|
it really depends on how user are using the Product Name field.
In Openbravo, products are identified by:
* Search Key (this is an internal field to speed up data entry and it is not relevant for this discussion)
* Product Name: unique name of the product
* Description: product description
If users were to universally use the product name to store the product code and the description for a human readable description, then you would be absolutely right, but I am not sure that is the case and it might be that users have adopted product name to store the human readable description.
We therefore need to be careful with this change and think it through before adopting it.
Here is an example. I have operations in the US and Italy (easy for me to translate) and I sell IP phones (I take this as an example as I have it on my desk).
Product code: "Linksys SPA942"
Product description: "Desktop style IP phone with two active lines, dual switched Ethernet ports, 802.3af PoE support, a high resolution graphical display, speakerphone, and a 2.5 mm head-set port".
If users enter the above product code in the product name, then there is no need to translate it to Italian.
However, if they enter "Desktop style IP phone Linksys SPA942", it should be translated to Italian as "Telefono IP per scrivania Linksys SPA942".
I know that perhaps this is not a best practice but before we conclude we need to:
1) Review what is displayed in the transactional screens (i.e. Sales Order): product name or description
2) Review what is printed in the reports: product name or description
3) Consider impact to existing users
On the other hand, I wonder what is the damage if we keep the functionality as it is and we continue to copy the product name in the trl table.
If you use codes that do not need translations, you can simply accept the propagated value for name and change the description.
Paolo, I completely agree that the name should be translatable, as it is currently. Sales order screens and all other screens seem to show the translation.
The problem appears when the user is not aware that the system has automatically created a translation by copying the base data. When you modify the original it seems that it has no effect as the old translations are still there.
So, if I understand your point, when we enable a new system language, we should avoid propagating the values for reference data.
If users want to define translations, they will do it manually. If not, the system should reference the "base language" record when a more specific record for a given language does not exist.
With this approach you would achieve both flexibility and minimal overhead.
Would you agree?
You probably are not going to like this but I would argue that such change should not be done as part of a defect fix (as it would change the behavior of the system under the users' feet) but should be targeted as a feature enhancement for a new release.
I'd agree. We did this change in our version already.
I was thinking of reporting this a feature request, but as the system admin can mess up with the client data I decided to select defect.
|2009-01-31 15:36||villind||New Issue|
|2009-01-31 15:36||villind||Assigned To||=> rafaroda|
|2009-01-31 15:36||villind||sf_bug_id||0 => 2552671|
|2009-01-31 15:36||villind||File Added: no-translations-for-user-data-12582.diff|
|2009-01-31 15:36||villind||Regression testing||=> No|
|2009-02-02 06:08||pjuvara||Note Added: 0012973|
|2009-02-02 10:25||villind||Note Added: 0012986|
|2009-02-02 11:25||pjuvara||Note Added: 0012996|
|2009-02-02 11:48||villind||Note Added: 0013000|
|2009-02-02 11:58||pjuvara||Note Added: 0013001|
|2009-02-02 12:08||villind||Note Added: 0013004|
|2009-02-02 16:50||pjuvara||Assigned To||rafaroda => rmorley|
|2009-02-02 16:50||pjuvara||Status||new => acknowledged|
|2009-02-02 16:50||pjuvara||Category||F. Localization => A. Platform|
|2009-02-02 16:50||pjuvara||Type||defect => feature request|
|2009-02-02 16:50||pjuvara||Tag Attached: Localization|
|2009-02-02 16:50||pjuvara||Tag Attached: ReleaseCandidate|
|2009-02-02 16:50||pjuvara||Assigned To||rmorley => pjuvara|
|2009-05-22 19:33||pjuvara||Assigned To||pjuvara => iciordia|
|Copyright © 2000 - 2009 MantisBT Group|