[wp-trac] [WordPress Trac] #28577: Allow language to be chosen during initial install

[WordPress Trac]

#28577: Allow language to be chosen during initial install
----------------------------+-----------------
 Reporter:  nacin           |      Owner:
     Type:  task (blessed)  |     Status:  new
 Priority:  normal          |  Milestone:  4.0
Component:  I18N            |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------
 The first step installing WordPress should be to choose a language. The
 rest of the install process would then be in that language.

 As outlined in http://make.wordpress.org/core/2014/05/21
 /internationalization-goals-for-4-0/, we'd like something like this:

 [[Image(https://make.wordpress.org/core/files/2014/05/osx-language.jpg)]]

 === Multiple workflows ===

 One issue that came up in #26879 (“friendlier welcome when installing
 WordPress”) is that setup-config.php is often not the initial entry point.
 A user installing WordPress through a hosting control panel is likely to
 be dumped onto the install screen (if not the dashboard directly).

 Thus, we need to keep in mind that either screen might be the “intro”
 screen. This introduces technical challenges: If the user’s first step is
 setup-config.php, we don’t actually have WordPress fully loaded at this
 point, which makes actually installing a language pack more difficult. The
 install step has WordPress loaded in full, just without database tables.
 We should look into making setup-config.php load “all” of WordPress to
 make these environments easier to code.

 === How to approach this ===

 There are two different ways to approach this: download language files
 immediately upon selection, or bundle barebones language files of the
 install screens for all supported languages. The latter is not the easiest
 thing to do (due to error messages and such, strings can come from all
 over) and also adds a delay to the adoption of new languages. The former
 would mean that we would want to pull a languages list from WordPress.org.
 (If we cannot reach WordPress.org, we would have no way of downloading the
 complete language pack, so this is not a big deal.) It’s still a bit of a
 challenge due to the split workflows problem.

 The plan is to download language files immediately upon selection.

 === Language suggestions ===

 WordPress.org already recommends a language based on the browser’s
 settings (Accept-Language header) as well as using a more rough lookup
 based on IP address blocks. (HTML5 location could be used, but unless
 we’re also going to use that to set the user’s timezone, it seems
 excessive for a “choose your language” for the moment, especially since
 location is not as preferred anyway.)

 Both would require the client to hit WordPress.org via JavaScript, versus
 a server HTTP request. We can do a server-side HTTP request to generate
 the list, then a client-side request to float recommended ones to the top.
 It’s possible to do it in two steps: the Accept-Language mapping can be
 done locally, while the IP-to-location table on WordPress.org has 2.9
 million entries and would require a round-trip. Of course, if a user has
 downloaded a localized package directly from a local WordPress.org site,
 that would be the top recommendation.

 === Locale variants ===

 Note that by language or locale we also must consider other translation
 variants, as there may be a language like Portuguese available in multiple
 locales (Brazil, Portugal) and further broken down by formal and informal
 variants. Each of these would be listed as their own “language.” c.f.
 #28303

 === API ===

 https://api.wordpress.org/translations/core/1.0/?version=4.0-alpha is
 functional.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28577>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform