0007301: Verify translations translates also user data, not just the application

Notes
(0012973) pjuvara (reporter) 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 (developer) 2009-02-02 10:25	Paolo, could you give an example why the product name translation should be copied automatically?

(0012996) pjuvara (reporter) 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 (developer) 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 (reporter) 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 (developer) 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.

Issue History
Date Modified	Username	Field	Change
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

Relationships [ Relation Graph ] [ Dependency Graph ]