[wp-meta] [Making WordPress.org] #6600: Update Language Suggest text

[Making WordPress.org]

#6600: Update Language Suggest text
--------------------------------+---------------------
 Reporter:  dd32                |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:
Component:  WordPress.org Site  |  Resolution:
 Keywords:                      |
--------------------------------+---------------------

Comment (by ryelle):

 There's another request to look into this [https://github.com/WordPress
 /wporg-mu-plugins/issues/365 on github], so I decided to check it out.
 [attachment:6600.diff] is where I've landed so far, but I'm not sure about
 it.

 The github issue also calls out that some locales have the wrong case —
 the API returns "galego", but proper case is "Galego". To fix that, I'm
 using `\GP_Locales::by_field( 'wp_locale', $guess['locale']
 )->native_name;` following how `plugin-directory/api/routes/class-locale-
 banner.php` works, and that returns the name correctly.

 Joining up the languages is where the trouble is. `wp_sprintf_l` is almost
 perfect, though I had to `require WPORGPATH . 'wp-
 includes/formatting.php';` to use it.

 Requesting a single, non-English language works:

 {{{
 $ curl "https://wordpress.org/lang-guess/lang-guess-ajax.php?uri=%2F" -H
 "Accept-Language: ja"

 <div id="lang-guess">WordPress は <a href='https://ja.wordpress.org/'>日本
 語</a> で利用可能です。</div>
 }}}

 Requesting two additional languages with English as the main language
 works:

 {{{
 $ curl "https://wordpress.org/lang-guess/lang-guess-ajax.php?uri=%2F" -H
 "Accept-Language: en-US,en;q=0.8,ko-KR;q=0.5,es-ES;q=0.3"

 <div id="lang-guess">WordPress is also available in <a
 href='https://ko.wordpress.org/'>한국어</a> and <a
 href='https://es.wordpress.org/'>Español</a>.</div>
 }}}

 Requesting more than two languages also works, but when the main language
 is not English, the joining string is not translated.

 {{{
 $ curl "https://wordpress.org/lang-guess/lang-guess-ajax.php?uri=%2F" -H
 "Accept-Language: es-ES,es;q=0.8,ko-KR;q=0.5,en-US;q=0.3,gl=0.1"

 <div id="lang-guess">WordPress también está disponible en <a
 href='https://es.wordpress.org/'>Español</a>, <a
 href='https://ko.wordpress.org/'>한국어</a>, and <a
 href='https://gl.wordpress.org/'>Galego</a>.</div>
 }}}

 I'm assuming the issue is that the translation system isn't actually
 loaded, which is why the `translate_gp` function is necessary.

 Should this endpoint be refactored to use the core REST API
 infrastructure? that ''seems'' like overkill, but could also be more
 future-dev-friendly (since we could use WP functionality as normal). Maybe
 we could share the code with the plugin directory endpoint? Also, there
 was a request in the Theme Directory redesign to
 [https://github.com/WordPress/wporg-theme-directory/issues/28 have the
 same feature there], so building up something a bit more reusable might be
 worth it.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6600#comment:1>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org