pb -> mba: please find someone to fix it.
You will find the sources here: svx/optgenrl.*. There is already a
differentiation between en-US, ru and other locales implemented.

bluedwarf -> mba: I can help you fix this issue. I will create a small patch for
CJK locales to solve this problem like "ru" locale.

Thanks a lot!

Created attachment 63357 [details]
The patch to swap the positions of last name field and first name field in ja, ko, zh-CN and zh-TW locales.

bluedwarf -> mba: I attached the patch to swap positions of first name field and
last name one in CJK locales. Not only positions but also tab orders (ZOrder)
are changed according to relations of those fields to provide natual feels of
UI. For accuracy, I also checked that this patch didn't cause regression in
en-US, de and ru locales, which means it doesn't affect any other locales except
zh_CN, zh_TW, ja, ko. Please check it out and integrate it in OOo source tree.

FYI: You can download the binaries I built and used for test;
http://ooopackages.good-day.net/pub/OpenOffice.org/Windows/i103200/

You can also find the results of this patches. I took some screenshots of
options dialog below;
http://ooopackages.good-day.net/pub/OpenOffice.org/Windows/i103200/results/

Hi naoyuki,

Please consider the localization of somewhere where use this setting. For
example, in the note.

Seems the display of the author are not localized in the note. So if you
localize this options setting, the display of author in notes need localized. or
it will display family name behind, which is not suitable for us Asians.

Now, I can find it used in:

File-Properties
File-Versions
Edit-Changes
Insert-Fields-Author
Insert-Fields-Other-Document-Author-Name
Insert-Note

Maybe it's used in more places. If there are, I'll tell you when I find them.

Hi,

Sorry, I find an other problem. If this work is done, and all the places using
author name are localized, an article written by western people will show
reversed name in our locale. For example, Jean Doe will be displayed as Doe
Jean. Feel something weird. This will affect OOo forever.

But current solution just affect the document created before OOo2.X. And we
needn't care about the localization of the mentioned places above, first name is
always at first. 

And First/Last is just the sequence of the name, For Western people, First name
is Given name, and for Asian, First name is Family Name. So the current solution
is reasonable I think.

So I suggest evaluating the effort and the problem. Does it worth doing?

Thanks

Hi,

I think this situation (Doe John problem) will not occur, because creator name
(John Doe) is hard coded in odf when inserting Note for example. I mean if John
Doe creates the document in English locale, the author name is always John Doe.
The name replacing will occur when user opens ODF file which has
<text:sender-firstname text:fixed="false"> element. The problem is not only 2.x
OOo produced ODF file. If other than OOo application produces ODF which has the
above element (it intends to show user's First Name - ODF spec says so, and the
term "First Name" always means "Given name" at least in Japan), OOo shows Family
Name for it. This is caused by OOo Asian UI leads user to input Family name into
First Name field. I believe it's a problem of OOo UI translation which needs to
be fixed.

>I think this situation (Doe John problem) will not occur

Thanks for the explanation, I'm not a developer, so I don't know much background
knowledge
about this. But I'm glad to know this answer. :-)

>The problem is not only 2.x OOo produced ODF file. If other than OOo application 
>produces ODF which has the above element 

Yes, I didn't think of this situation. I looked into MS word and found it not
separating the First Name and Last Name. Just a Name field exists.
For other software save as odf file, I think it still depend on the solution of
that software. If it has different solution(like a simple solution OOo currently
used), probably issue will still exist.
Or can we treat this as MS does, Combine the 2 fields as one Name field? Maybe
this is another solution.

>and the term "First Name" always means "Given name" at least in Japan

Another knowledge for me. I didn't know "First Name" are used in Japan. So seems
this does have effects to Japanese. So it's worth doing. Because Chinese never
use "Last Name" and "First Name", so the current solution is already a perfect
solution. :-) With your work, this will be a perfect solution for Asian. Thanks.

redflagzhulihua:
As nayoki said, in general, (hopefully almost all) people in Japan know that
"first name" means given name and "last name" means family name. We seldom use
the expression "first name", but if we find it, then we consider it as give
name, and vice versa. "First" and "last" don't mean the sequence as long as they
are connected to name. To be more precise, I looked up in two different
English-Japanese dictionaries and both of them read that "first name" was given
name ("名" in Japanese) and last name was family name ("姓" in Japanese). This
is the common translation from English into Japanese.

Anyway, I know that we have to localize the way to show our names in note or
wherever it concerns in correct order according to the locale or somehow, but it
should be discussed somewhere else and we should file another issue for that.

BTW, in my opinion, we don't have to share the same solution among CJK or among
Asian languages if we have different cultures or standards. I don't know how
about in China. If the situation is different, you can choose another solution
different from Japanese. If the changes made by my patch are not acceptable for
Chinese, I can get rid of the corresponding lines for Chinese, though we will
apply this patch at least for Japanese as we discussed in our Japanese mailing
list. So please kindly give us "go" sign, then this patch goes as it is.
Otherwise, I will remove the lines related to Chinese from my patch and ask the
developer team to accept a new patch, which will preserve the current solution
of OOo 3.0/3.1 only for Chinese. I think the best way to look up an
English-Chinese dictionary.

Hi bluedwarf,
Thank you for the comment.
As my last comment said, your work will make it perfect for Asian, 
include China. So please go ahead, thank you.
About "first name" and "last name", we know they means "given name" 
and "family name" for westerns. And dictionary also translate them
to "名" and "姓". But we consider this is a convention for westerns.
Because they always put given name at the beginning of full name, so
"first name" is "given name" and vise versa. But in China, "family name"
first, so "first name" and "last name" are not strictly used as "given 
name" and "family name". We know "first name" is "given name", and the
dictionary also says so, but most of Chinese don't speak English, and 
we usually consider that's a rule for westerns. More and more people 
in China place the "family name" first as English name. Include some 
formal press. Like "Chinese president Hu jintao" in CRI(China Radio 
International). So people tend to treat "first name" literally. western eople
can hear explain like this in China: "For Chinese people, the first name
is Family name and the last name is given name, this different from your 
western people." :-)
Conclusion: This enhancement is a perfect solution, what I worried about was the 
problem may arise. and Noryuki has told me on worry. So please get Chinese
build involved. :-)
Thanks,

mba: Please integrate my patch as it is. We reached an agreement.

redflagzhulihua:
JFYI, you showed me a very very good example about name order, which clarifies
the diffrent conventions about name in English context between China and Japan.
In short, people in Japan put given name in first when we talk and write in
English (and probably other western languages).

For example, in Japan, when someone asks us "Who is the prime minister in your
country?" in English, then we say "Taro Aso" in the western order. "Taro" is his
given name. Not only daily conversion but most newspapers follow this western
convention as long as they write English articles including formal ones.
However, when we are asked the same question in Japanese, of course, we always
answer "Aso Taro" in the eastern order and all newspapers in Japanese also do so.

That means people in Japan use the eastern order as long as we talk and write in
our own language, but, on the other hand, we follow the western order for
English conversations and articles. We swap our family names and given names
according to the context of languages.

Here is a good but very rough analysis about the comparison of diffrent
conventions of Chinese and Japanese names in English context, which is the
number of hit pages in Google.com (2009/7/9):

 * "hu jintao" (Eastern order) 2,240,000
 * "jintao hu" (Western order) 25,200
 * "aso taro"  (Eastern order) 35,800 
 * "taro aso"  (Western order) 805,000

It makes us clear that, while Japanese names often follow the western order in
English context, Chinese names usually keep their eastern order even in English
sentences. I think this difference caused different interpretations of the terms
"first name" and "last name" between Japanese and Chinese and made us in
discussion. As you said people in China would treat "first name" literally, but
people in Japan usually don't do so.

So please keep in mind that you can still choose another solution that you
preserve the current solution of OOo 3.0/3.1 and re-translate "first name" in "
姓" and "last name" in "名" everywhere in 3.2. I'm not sure this is a smart
solution for Chinese people, but it's your option and just for your information.

Anyway, I would like to let this patch go first and go to the next step that
localize the name order in other places.

Thanks a lot!

svx and forms had some stupid dependencies on configmgr, ucb and fileaccess. I
removed them (of course without a problem)

sorry, wrong issue. :-(

*** Issue 102553 has been marked as a duplicate of this issue. ***

*** Issue 61898 has been marked as a duplicate of this issue. ***

Is it possible to discuss the following way?

 - stop  using terms: first name, last name, and initial

 - start using terms: given name, family name, and initial
                      or family name 1, given name, family name 2, and initial
                      or more culturally depending terms

A locale of the UI will determine the order of fields corresponding to the terms.


Off the topic: 
As far as I know, many professional users in Japan using OpenOffice.org in the 
following way despite Japanese translations of UI to practically live with a 
current implementation of OpenOffice.org:

 - Fill a first name field with their family name.
 - Fill a  last name field with their given name. 

The way above has completely solved a problem of the order issue if they
intentionally ignore the translations in the UI without waiting for a real 
resolution. Their family name (i.e. first name) will be displayed prior to 
their given name (i.e. last name) everywhere in OpenOffice.org as they expect. 

So there might be lots of existing ODF files in Japan with first and last names 
in a reverse order. We, however, would have no practical solutions for the 
wrongly created ODF files. 

What we could have learned from the reality would be to solve this type of 
cultural issues as soon as possible to prevent further abuse of UI.

How can we find the source codes relevant to the order of first and last name data?

There would be, at least, 
 - Tools - Options - %PRODUCTNAME - User Data
 - Insert - Fields - Author
 - Insert - Notes
 - Edit - Changes - Show; Accept of Reject; ...
 - Displaying a meta data information on Windows Explorer 
 - Meta data in an saved-as Microsoft Word file
 - Data accompanied with /Author operator in an exported PDF file

This is a just my current thought. 
I think we should wait for a change of the order of fields in the 

 Tools - Options - %PRODUCTNAME - User Data 

until the order of the fields, at least, in the following functions has been 
culturally and appropriately corrected. Otherwise users might get further confused. 

 - Displaying a meta data information on Windows Explorer 
 - Insert - Notes
 - Edit - Changes - Show; Accept or Reject; ...

Idea 1) 
 - Consider a first name as a text data displayed at the first position.
 - Do not touch any existing source codes relevant to a name of author.
 - Translate a term "first name" into "FAMILY NAME" in Japanese.

Idea 2)
 - Consider a first name as a given name. 
 - Enhance everywhere in the source codes relevant to a name of author.
 - Translate a term "first name" depending on the target culture. 

Idea 3)
 - Introduce another layer which treats cultural differences and converts 
   a concept of given and family names into cultural depending fields. 

(Data input layer)
   User enters his/her given name and family name. 

(Translation layer)
  In Western 
   Given name ---> field number 1
   Family name --> field number 2

  In Japanese
   Given name ---> field number 2
   Family name --> field number 1

(Rendering layer)
   The field number 1 is followed by the field number 2.
   The field number 2 is followed by the field number 3, 
   ...

Any more idea?

Just for the records: I have applied the patch from bluedwarf in my cws
mba32issues02 (hg based, dont' search for it in svn, there is only an old
version of the CWS that didn't survive a rebase). I understood that this should
be OK for now.

tora -> bluedwarf: 
Could you refactor your patch to encapsulate a logic like this?
This is just an idea. You can devise it in your preferable way.

// $SOLARVER/$INPATH/inc/offuh/com/sun/star/lang/Locale.hpp
#include <com/sun/star/lang/Locale.hpp>
#include <vcl/settings.hxx>

class NameOfPerson
{
public:

    NameOfPerson();
    ~NameOfPerson();

    // The default locale could be internally retrieved from
AllSettings::GetUILocale()
    void setUILocale( const ::com::sun::star::lang::Locale& rLocale );
    const ::com::sun::star::lang::Locale& getUILocale();


    // accessors for meaning layer
    void setFamilyName( const OUString& rousName );
    void setGivenName( const OUString& rousName );

    OUString& getFamilyName();
    OUString& getGivenName();

    
    // accessors for presentation layer
    void setFirstPositionNameText( const OUString& rousName );
    void setSecondPositionNameText( const OUString& rousName );

    const OUString& getFirstPositionNameText();
    const OUString& getSecondPositionNameText();
    const OUString& getInitial();

    const OUString& getLabelTextOfFirstPositionName();
    const OUString& getLabelTextOfSecondPositionName();

    const OUString& getCombinedNameTextForTheGivenLocale( sal_Unicode cDelimiter
= 0x0020 );
};


IMHO, we should not have these type of code fragments here and there 
within the entire OpenOffice.org source code tree: 

    if ( LANGUAGE_JAPANESE == eLang ||
        LANGUAGE_KOREAN == eLang ||
        LANGUAGE_CHINESE_TRADITIONAL == eLang ||
        LANGUAGE_CHINESE_SIMPLIFIED == eLang)

    // swap "first name" field and "last name" field
    Point aPosTmp = aFirstName.GetPosPixel();
    aFirstName.SetPosPixel( aName.GetPosPixel() );
    aName.SetPosPixel( aPosTmp );
    aFirstName.SetZOrder( &aName, WINDOW_ZORDER_BEHIND );

bluedwarf->tora: Thanks a lot for your comment. I know we should take more
comprehensive solutions and carry out code refactoring. In my point of view,
this fix just fulfills the request about name order in Option dialog reported in
issue 89362 because the translation changes held in that issue caused other
problems and they were reverted. I consider this fix as a temporary fix. So you
should post your ideas in other places like issue 103401. If desired, I can help
you.

An issue 104143 has been just filed to cover comprehensive, alternate resolution 
of this topic. 

So shall we hand over this to QA? Is this how it should be in 3.2?

This is a current thought of mine.
 - For 3.2, apply the patch attached in this issue and go on. 
 - For OOo later, consider issue 104143 to eliminate further confusions. 

What do you think, bluedwarf?


IMHO, users might overestimate an outcome of this issue. They might think that
reversing the positions of first and last name fields in the dialog of Tools - 
Options - %PRODUCTNAME - User Data will solve everything related to the order 
of first and last names. 
In reality, nothing will be solved except the one in the Tools - Options. 

There are many possible locations a user name will be used. 
E.g Author, Modified-by, and Printed-by in the File - Properties, 
    Commenter of Insert - Notes, 
    Editor in the Edit - Changes,
    Who-save in the File - Versions, ...
    Author displayed as one of meta data in Windows Explorer, 
    Adobe Reader, Microsoft Office, ... 

Most of them come from one of the properties stored in DoucumentInfo 
http://api.openoffice.org/docs/common/ref/com/sun/star/document/DocumentInfo.html
and/or XDocumentProperties
http://api.openoffice.org/docs/common/ref/com/sun/star/document/XDocumentProperties.html

The property 'Author' is just a single string. So why do we need to input 
first, last, given, family, father, mother, middle, etc. names separately?

Supporting all possible types of name fields depending on a target culture 
determined by a type of user interface language would be one of the solutions 
like this issue. 

Meanwhile, Putting them into a single text field regardless of the target 
culture would be also one of the solutions. 
The latter is the issue 104143.

There is a function that returns author by concatenating a first name, a space, 
and a last name. 

svx/source/items/flditem.cxx
XubString SvxAuthorField::GetFormatted() const
{
	XubString aString;

	switch( eFormat )
	{
		case SVXAUTHORFORMAT_FULLNAME:
			aString  = aFirstName;
			aString += sal_Unicode(' ');
			aString += aName;
		break;


I am not sure, the above code is the only code to handle first and last names. 
There might be other codes somewhere. 


Is it possible to temporarily enhance the code to recognize target cultures 
like this in a separate issue?

		if ( Western languages )
		{
			// Normal order
			aString  = aFirstName;
			aString += sal_Unicode(' ');
			aString += aName;
		}
		else if ( East Asian languages )
		{
			// Reverse order
			aString += aName;
			aString += sal_Unicode(' ');
			aString  = aFirstName;
		}
		else if ( ... )

OK, for now I know enough. So I will take the patch for 3.2 as it is.
Thanks to all who helped getting there!

@tm: please verify

bluedwarf -> mba: Thanks a lot!

bluedwarf -> tora: First of all, don't mess up this issue anymore. I know you
have a lot of options and need more intensive discussion for a comprehensive
solution, but this issue is not suitable for the discussion. Could you conduct
an online discussion place like BBS, IRC, ML or something else? I agree with the
point that we should take care this problem much more for later versions, but it
doesn't make sense that you express your opinion and I comment on it here. (BTW,
I disagree with all your ideas in term of compatibility.) I doubt we can reach
an agreement soon because there are many things we have to take into account.
I'm sorry but I have to mention this point not to confuse those who are involved
in this issue. 

tora->bluedwarf:
Thank you for your careful considerations. 

Could we start discussions on this topic to really fulfill North East Asian users 
as well as Western and other cultural users in dev@l10n?

I would suggest to create a naming service in i18npool to handle the issue,  define the format in locale 
data for each language.

This Family name first style is not only for Japanese and Chinese, I believe Vietnam is also using this style. 
To make it flexible for different language, it must be defined in locale data.

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. 

@BLUEDWARF: I have builds of my CWS ready. I think it would make a lot of sense
if you would verify that the final result of it is what you wanted to achieve.
Please let me know if you want to do that and which platform you want to test
on. I have builds for Windows and Linux, a Mac build would require a few hours more.

Reassigned to me.

@mba: OK, I will. Windows version will be fine, but do you have language packs?
I need en-US and at least one of CJK because the behavior depends on locale. If
you don't have any of CJK, then I will check my patch after your CWS is
integrated into the master.

sba will test the issue anyway, I justed wanted to make sure that everything is
as you wanted it to have.

I just had the idea that perhaps creating a screen shot and attaching it here
could be enough.  What do you think?

That'll be fine. Go forward it.

Created attachment 64620 [details]
screenshot of changed options dialog

I've attached a screenshot showing a "Japanese" version of OOo with english UI
resources (but UI locale set to Japanese). I did it that way as it saved me from
building one version more (would have taken several hours to build).

As you can see the order of the edit fields is reversed.

@mba: Thank you for your effort. I looked at the picture and confirmed the name
order was reversed. That's OK. Please go ahead.

Verified in CWS mby32issues02.

Typo in cws name : correct name is mba32issues02

Regards
JBF

OK in OOO320_m11. Closed.