Use given name / surname in place of first name/lastname

[Zhang Weiwu]

I recall there was a specification like ASN.1 or RFC or something that recommends surname and given name over last name and first name, and require so on some context. at least for addressbook management the LDAP schema "person" requires so.

Reason: not all culture order is given name before surname. This makes the system difficult to deploy. A simple change is an option per person that how should the name be ordered. A better change is to make schooltool person profile following ASN.1. That is, as far as I can recall, use "title", "givenName", "surname", "generationQualifier" to replace "prefix", "last name", "first name", "suffix". This offer better compatibility with PIM/groupware integration too.

[Tom Hoffman (tom-hoffman)]

We definitely need to straighten this out a bit.

One thing I'm unclear on is how much of this needs to be changed in the data model -- does it matter if we change variable names? Another thing I'm not sure about is whether this suggests that we need to think about the default in SchoolTool being a "base" i18n neutral translation with separate "US English" etc. translations. That is, "given name" and "surname" are clearer to someone translating and using the application in China, but not really what you'd use in the US. And you certainly wouldn't use "generationQualifier" in the UI anywhere.

[Zhang Weiwu (zhangweiwu)]

Hi. I am thinking base name being given name / surname and US translation file put it to first name / last name. It surprised me a little to know in the most cosmopolitan country (US) people wouldn't want given name / surname on the UI, after all these Japanese immigrants and Chinese visitors. I haven't been out of China though.

So in short not sure of others but I want to see change in variable name + all translation files. I am not sure if this is too fundamental change to the system.

[Justas Sadzevičius (justas.sadzevicius)]

I investigated the issue quite a bit deeper, see the resulting related blueprint.

Just before the release is not a very good time to change base translations. Changes in variable names are changes in the data model and it requires migration, so I'd like keep such changes rare. Changing them once would be perfect...

Introducing a more flexible model on the other hand will likely break the API compatibility for software like CanDo - again I'd like to do that after the Lucid release.

This is a very important topic and I'd like to work one step at the time towards generic solution:
1) split name data from UI, add rudimentary data structures, keeping the look and functionality identical
2) start adding important features (in parallel):
- Easter/Western support
- Chinese/Western name field schemas
...

[Tom Hoffman (tom-hoffman)]

Yes, we can put this off.

[Tom Hoffman (tom-hoffman)]

I'm marking this "won't fix" because what we ended up doing is essentially letting the administrator set which name was most important functionally for sorting, etc. It wouldn't make sense to do that AND switch to name/surname.