To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=103200
------- Additional comments from [email protected] Wed Sep 2 04:49:37 +0000 2009 ------- tora -> khong: I completely agree with you from a technical point of view if we keep going in this direction. The logic, how to determine the order of the fields and how to concatenate them into a single, formatted, full name, should be moved to either locale data or configuration data. Local data http://svn.services.openoffice.org/ooo/trunk/i18npool/source/localedata/data/ Configuration data http://svn.services.openoffice.org/ooo/trunk/officecfg/registry/data/org/openoffice/Office/ all: (this should be on a ML, as bluedwarf suggested, though) I would like to suggest turning a direction towards user requirements. We are developing software products at reasonable cost. Don't you think so? Implementing such complex requirements perfectly and keeping update source codes and/or locale data every time one native language project comes to ask developers to tweak its settings and testing the modifications repeatedly is highly costly. If the function -- separately specifying individual name fields -- is really mandatory, keep going with such expensive budget and make source codes much complexer and complexer. But, hold on, think again about the requirements of office suite products. What other competitive and/or similar software products possess separate name fields? Could you try to name it? Microsoft Office, Thunderbird, AutoCAD, ... as far as I know, no other software product spends their project budget for such complex name field related functions. We can develop a migration function that converts old user data prepared with previous versions of OpenOffice.org to new user data for being installed version of OpenOffice.org. Compatibility of what? How much percentage of users are currently using that? Is there no way to migrate if we remove such rarely used functions? It is software. So we can implement any requirements. But, don't forget about costs - design, development, translation, documentation, testing, updating, bug-fixing, and so on. Requirements are defined by users, which we cannot control. What we can manage is how to integrate the requirements at what cost. I think we don't need to deliver the perfect implementation, but to offer reasonable implementation. For 3.2, no further discussion would be needed if nobody realizes what this patch solves and what does not. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
