WordPress.org

Making WordPress.org

Opened 19 months ago

Closed 18 months ago

Last modified 9 months ago

#1728 closed task (fixed)

Add locale banner on plugin detail page

Reported by: samuelsidler Owned by: ocean90
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

One way to improve the visibility of the localized plugin directories is to show a banner on the plugin detail page, if a plugin is translated into a locale relevant to the user.

We already have some code that uses GeoIP and accept-lang headers (I believe) to tell users if either WordPress or the forums are available in their language. We can reuse some of that code here. One difference, though, is that we'll want to check if a plugin is translated into those languages and only show those. The banner should probably read something like...

This plugin is also available in German.

But, you know, translated like the current string is on the homepage, download page, and forums. And with other languages in parenthesis. (Note that we shouldn't list all languages the plugin is available in at this location.)

We already have some code that does something similar in the current repository. Perhaps we can reuse it?

Attachments (3)

no-translations.png (155.0 KB) - added by ocean90 18 months ago.
translations-on-en-us.png (2.7 MB) - added by ocean90 18 months ago.
translations-on-de.png (2.7 MB) - added by ocean90 18 months ago.

Change History (19)

#2 @obenland
18 months ago

  • Milestone set to Plugin Directory v3 - M5
  • Owner set to ocean90
  • Status changed from new to assigned

#3 @ocean90
18 months ago

In 3460:

Plugin Directory: First pass for a locale banner on plugin detail page.

Adds a new REST API endpoint and suggests languages based on the HTTP_ACCEPT_LANGUAGE header.

See #1728.

#4 @ocean90
18 months ago

In 3463:

Plugin Directory: Change CSS class name for locale banner and add the missing Sass file.

See #1728.

#5 @ocean90
18 months ago

In 3474:

Plugin Directory: Add a link to translate.wordpress.org if a plugin isn't translated yet.

See #1728.

#6 @ocean90
18 months ago

In 3491:

Plugin Directory: Don't display a locale banner if a plugin is translated into the locale of the current site.

See #1728.

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


18 months ago

#8 follow-up: @ocean90
18 months ago

What's missing here:

  • Do we want to display locale banners on local sites? This would only happen if a user has multiple languages in the header defined.
  • Should the banners be dismissable?
  • I missed an important part: The banner on https://wordpress.org/plugins-wp/akismet/ needs to be translated into the first language.

cc: @obenland

#9 in reply to: ↑ 8 @samuelsidler
18 months ago

Replying to ocean90:

  • Do we want to display locale banners on local sites? This would only happen if a user has multiple languages in the header defined.

Nope. I think we could, but I'd rather list all available translations in the Contributors & Developers section (on all locales).

  • Should the banners be dismissible?

Nope.

Yes, please. :)

#10 @ocean90
18 months ago

In 3534:

Plugin Directory: Enhance logic for the locale banner.

  • Show suggestions for other languages only in the English directory.
  • Translate banner into the first language.
  • Tweak the strings.

See #1728.

#11 @ocean90
18 months ago

In 3540:

Plugin Directory: Fix locale banner for browsers which are sending an en-us language header.

See #1728.

#12 @ocean90
18 months ago

In 3556:

Plugin Directory: Change the API endpoint for locale banners to /locale-banner so it can be used for other requests.

See #1728.

#13 @ocean90
18 months ago

In 3559:

Plugin Directory: Display a locale banner on non-plugin details pages.

See #1728.

#14 follow-up: @juanfra
18 months ago

Hi,

This is looking great, and it is actually awesome. I really like it. The only thing that I doubt about is the accuracy of the suggested language. At the moment it is getting the locale from the "languages" the user has configured in his browser. Shouldn't it be better if we base the location on the user current location via JS or even using an IP location service?

Best,
Juanfra.

#15 in reply to: ↑ 14 @samuelsidler
18 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

Replying to juanfra:

Shouldn't it be better if we base the location on the user current location via JS or even using an IP location service?

We'll play around with it, but we've gotten a lot of negative feedback with the current iteration, which uses an IP location service. That one is visible on the homepage, support forums, and download page.

Everything on this ticket is fixed. Resolving as such.

#16 @samuelsidler
9 months ago

  • Milestone Plugin Directory v3 - M5 deleted

Milestone Plugin Directory v3 - M5 deleted

Note: See TracTickets for help on using tickets.