Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0007301
TypeCategorySeverityReproducibilityDate SubmittedLast Update
feature request[Openbravo ERP] A. Platformmajoralways2009-01-31 15:362009-05-22 19:33
ReportervillindView Statuspublic 
Assigned Toiciordia 
PrioritynormalResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version2.40MP1SCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0007301: 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.

Proposed SolutionRemove automagic translations for user data.
TagsLocalization, ReleaseCandidate
Attached Filesdiff file icon no-translations-for-user-data-12582.diff [^] (2,124 bytes) 2009-01-31 15:36 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]

-  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


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker