Context Navigation

← Previous Ticket
Next Ticket →

#1673 closed enhancement (fixed)

Forum registration form i18n

Reported by:	Nao	Owned by:	obenland
Milestone:		Priority:	normal
Component:	Login & Authentication	Keywords:	needs-patch
Cc:

Description

The registration forms for i18n forums are in English only. With the new reCaptha, we are getting an increased number of inquiries from users who are unable to register because they don't understand the question or the error message.

https://ja.wordpress.org/support/register.php redirects to https://wordpress.org/support/register.php

For example, it's not easy for some non-English speakers to select images of "construction vehicle" or
recreational vehicle (RV)" :(

Change History (29)

#1 in reply to: ↑ description @netweb
9 years ago

Replying to Nao:

https://ja.wordpress.org/support/register.php redirects to https://wordpress.org/support/register.php

For example, it's not easy for some non-English speakers to select images of "construction vehicle" or
recreational vehicle (RV)" :(

Localised register screen sounds like the best option and using the ja localised version of reCAPTCHA.

#2 @Otto42
9 years ago

At present, we do not specify the language code to be used for the ReCaptcha service, meaning, according to the documentation, that it attempts to auto-detect the user's language.

https://developers.google.com/recaptcha/docs/display#config

#3 @Nao
9 years ago

My apologies, I was testing on a browser set to English. I don't have the information on the user who reported the issue with reCaptcha, but they may have been using something similar or very old.

Aside from the reCAPTCHA, the issue with the error message being in English is still present. Often times, users don't understand that the username is rejected because of an existing account (many try to enter their .org install username). This issue isn't as bad as untranslated reCAPTCHA being a block, though.

If it's not very easy to localize the form, I understand - still wanted to share the feedback.

#4 @SergeyBiryukov
8 years ago

This is yet another example (after #1868) that the long-term plan of merging forum profiles with WP.org profiles (#518) sounds good in theory, but would lead to issues if not done properly.

Forum profiles and registration pages should have UI in the forum language, whereas WP.org profiles are intentionally English-only. Merging them would require some kind of i18n roadmap for WP.org profiles.

Now that the forums are on bbPress 2.x, this might be easier to fix, however login.wordpress.org still links to bbPress 1.x registration page at the moment, see #2058.

#5 @SergeyBiryukov
8 years ago

With [4470], i18n of the registration form seems doable :)

@ocean90: wporg-login theme appears to support translation. If the strings were added to Meta projects, we could probably link the forums to translated registration forms. What needs to happen for that?

This ticket was mentioned in Slack in #meta by sergey. View the logs.

8 years ago

#7 @dd32
7 years ago

Component changed from International Forums to Login & Authentication

#8 follow-up: ↓ 9 @obenland
7 years ago

@SergeyBiryukov @ocean90 Is it possible this was fixed with [6493]?

#9 in reply to: ↑ 8 @SergeyBiryukov
7 years ago

Replying to obenland:

Is it possible this was fixed with [6493]?

https://ja.wordpress.org/support/ still links to English registration form: https://login.wordpress.org/register, so I don't see any changes here.

#10 @obenland
7 years ago

In 6638:

Add locale detection plugin.

Sets a blog's locale to the users preferred locale.
Derived from Browse Happy's Browse_Happy_Locale.

First step in localizing login.wordpress.org.

See #1673.

#11 @obenland
7 years ago

In 6640:

Locale detector: Save locale in cookie

Also switches to using the actual list of available locales.

Props ocean90.
See #1673.

#12 @obenland
7 years ago

In 6643:

See #1673.

#13 @obenland
7 years ago

In 6644:

Locale Detection: Let GET param override Cookie

Allows for switching locales based on context.

See #1673.

#14 @obenland
7 years ago

In 6645:

While it was necessary in Browse Happy, Locale Detection runs before WP_Locale gets instantiated and it's not necessary here.

Props ocean90.
See #1673.

#15 @obenland
7 years ago

In 6646:

WPorg SSO: Use default strings in wp_login_form()

Also changes remaining textdomain to wporg for easier translation.

See #1673.

#16 @obenland
7 years ago

The login form is localized, the one remaining thing to do here would be to add the locale parameter to the registration URL. Can anyone point me to where I can change that?

#17 follow-up: ↓ 18 @ocean90
7 years ago

@obenland In the SSO library I'd say. For the registration URL see https://meta.trac.wordpress.org/browser/sites/trunk/common/includes/wporg-sso/wp-plugin.php?rev=6646#L283. Something like if ( 'en_US' !== get_locale() ) { add_query_arg( 'locale, get_locale(), $url }. Should we do the same for the login URL?

#18 in reply to: ↑ 17 @obenland
7 years ago

Replying to ocean90:

Should we do the same for the login URL?

I'd be in favor of that.

Something like if ( 'en_US' !== get_locale() ) { add_query_arg( 'locale, get_locale(), $url }.

I was mulling over that and feel like it might be best to always maintain the language context of the referring site, even en_US. It would feel odd to me if I wanted to answer an English forum post and first get redirected to a German login form, and then back to the English post. What do you think?