Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007301Openbravo ERPA. Platformpublic2009-01-31 15:362009-05-22 19:33
Reportervillind 
Assigned Toiciordia 
PrioritynormalSeveritymajorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOS5OS Version
Product Version2.40MP1 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0007301: Verify translations translates also user data, not just the application
DescriptionOnly 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.

Steps To Reproduce
Proposed SolutionRemove automagic translations for user data.
Additional Information
TagsLocalization, ReleaseCandidate
Relationships
Attached Filesdiff no-translations-for-user-data-12582.diff (2,124) 2009-01-31 15:36
https://issues.openbravo.com/file_download.php?file_id=784&type=bug
Issue History
Date ModifiedUsernameFieldChange
2009-01-31 15:36villindNew Issue
2009-01-31 15:36villindAssigned To => rafaroda
2009-01-31 15:36villindsf_bug_id0 => 2552671
2009-01-31 15:36villindFile Added: no-translations-for-user-data-12582.diff
2009-01-31 15:36villindRegression testing => No
2009-02-02 06:08pjuvaraNote Added: 0012973
2009-02-02 10:25villindNote Added: 0012986
2009-02-02 11:25pjuvaraNote Added: 0012996
2009-02-02 11:48villindNote Added: 0013000
2009-02-02 11:58pjuvaraNote Added: 0013001
2009-02-02 12:08villindNote Added: 0013004
2009-02-02 16:50pjuvaraAssigned Torafaroda => rmorley
2009-02-02 16:50pjuvaraStatusnew => acknowledged
2009-02-02 16:50pjuvaraCategoryF. Localization => A. Platform
2009-02-02 16:50pjuvaraTypedefect => feature request
2009-02-02 16:50pjuvaraTag Attached: Localization
2009-02-02 16:50pjuvaraTag Attached: ReleaseCandidate
2009-02-02 16:50pjuvaraAssigned Tormorley => pjuvara
2009-05-22 19:33pjuvaraAssigned Topjuvara => iciordia

Notes
(0012973)
pjuvara   
2009-02-02 06:08   
Rafa: let's discuss this carefully as part of triage. I am not convinced this is a defect.
(0012986)
villind   
2009-02-02 10:25   
Paolo, could you give an example why the product name translation should be copied automatically?
(0012996)
pjuvara   
2009-02-02 11:25   
Ville,
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
(0013000)
villind   
2009-02-02 11:48   
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.
(0013001)
pjuvara   
2009-02-02 11:58   
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.
(0013004)
villind   
2009-02-02 12:08   
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.