The user's preferred timezone and language may be retrieved using SREG or AX. We should do that when OpenID is used to create an account.

Especially the timezone is complicated. Auto-detection of timezones only works to some extent. E.g. my timezone is auto-detected to Europe/Paris instead of Europe/Copenhagen (I live in Copenhagen). The two cities belong to the same timezone, so either timezone will work, but some users may get the impression that they have to select the actual city they live in.

CommentFileSizeAuthor
#8 openid-timezone-language-2.patch13.05 KBc960657
#3 openid-timezone-language-1.patch12.51 KBc960657
#2 openid-sreg-1.patch3.03 KBc960657
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented

Any documentation on how to do that? Is there any chance that the timezone names provided by that means matches ours (which uses the defacto Olsen database)?

c960657’s picture

c960657 CreditAttribution: c960657 commented
FileSize
openid-sreg-1.patch3.03 KB

http://openid.net/specs/openid-simple-registration-extension-1_0.html

The relevant keys are openid.sreg.language and openid.sreg.timezone. For AX, there is http://axschema.org/pref/language and http://axschema.org/pref/timezone (and probably also corresponding http://schema.openid.net variants).

WRT language codes, the standard refers to ISO639, but AFAICT it does not tell which part of the standard should be used. ISO639 defines both 2-letter and 3-letter codes.

The timezone names are from the Olson database.

Here is an old patch that I wrote last summer (time flies) but never finished. The implementation is now much easier than it was back then because of the recent restructuring of the auto-registration code flow in #395340: Email verification not enforced with OpenID auto-registration.

c960657’s picture

c960657 CreditAttribution: c960657 commented
Status: Active » Needs review
FileSize
openid-timezone-language-1.patch12.51 KB

Updated patch. The timezone and language are handled in two different ways because their respective UI is handled by the locale and system modules, and their hook_form_alter()s are invoked on each before and after the openid module, respectively.

Status: Needs review » Needs work

The last submitted patch, openid-timezone-language-1.patch, failed testing.

c960657’s picture

c960657 CreditAttribution: c960657 commented
Version: 7.x-dev » 8.x-dev
Status: Needs work » Needs review
c960657’s picture

c960657 CreditAttribution: c960657 commented

#3: openid-timezone-language-1.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, openid-timezone-language-1.patch, failed testing.

c960657’s picture

c960657 CreditAttribution: c960657 commented
Status: Needs work » Needs review
FileSize
openid-timezone-language-2.patch13.05 KB
sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Status: Needs review » Reviewed & tested by the community

Looks good to me.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Status: Reviewed & tested by the community » Fixed

I'm a bit turned around that we have system module implementing user hooks, wtf, not the fault of this patch though.

Patch looks fine to me as well, it's just fixing openid module to work with the spec better, and adds test coverage. Committed/pushed to 8.x.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

@c960657: Not sure whether this was supposed to be backported - if so, please re-open and tag accordingly, thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

This code got a followup fix in #1527720: OpenID language matching finds least specific instead of most specific match just in case it is considered again for backporting.