[wp-trac] [WordPress Trac] #18200: Language Packs

[WordPress Trac]

#18200: Language Packs
---------------------------------+------------------
 Reporter:  nacin                |       Owner:
     Type:  task (blessed)       |      Status:  new
 Priority:  normal               |   Milestone:  3.6
Component:  Upgrade/Install      |     Version:
 Severity:  normal               |  Resolution:
 Keywords:  3.4-early has-patch  |
---------------------------------+------------------

Comment (by dimadin):

 == Non-blocking ==

 I disagree that this needs to wait !WordPress.org infrastructure before
 inclusion in core. The way this should work based on proposed patch is
 that when there is no !WordPress.org infrastructure it won’t return
 anything language related so it would simply work as before.

 This means that infrastructure might get ready late in release cycle, or
 even after release, and in that time we’ll have core side done and tested.
 Core support doesn’t require API (api.wordpress.org) support, it’s only
 required if you want to have it as an official feature.

 Probably, in beginning there will be need for some change in API’s
 response so that response can be able to hold information for a few
 language-core/plugin/theme combinations that would have pre-made static
 language packages for testing purposes. This shouldn’t require too much
 changes.

 == Testing ==

 I tested patch by @dd32. Everything in install/upgrade of
 core/plugins/themes worked as usual so there is nothing breaking. For
 packs, even if response had language information, nothing would happen
 since patch doesn’t save that data.

 So I modified it (see attached patch) with presumption that structure of
 API responses is same. Response for core is already structured so that
 there are a couple of keys with different content and it would simply
 access one more for languages. Plugins and themes responses offer arrays
 where first level keys are names of plugins/themes so it just checks for
 language_updates key and unsets it.

 Then I forced response to hold language information with pre-made packages
 (see attached plugin).

 With language_updates available, upgrader would download and extract
 language files as expected.

 == Improvements ==

 There are possible improvements to this core workflow:

 * API responses for plugins/themes should change to be in line with core
 one (current array of updates can be under offers key, with languages
 under language_updates).
 * API requests should have one more key along installed_languages that
 carries language codes so that site can get language files even if there
 aren’t installed language files.
 * On unistallation of plugin/theme, associate language files should be
 deleted too.
 * Action links on upgrader screen should be maybe shown after language
 updates are done to avoid possible interruption caused by user’s click on
 those links.

 == GlotPress ==

 On GP side, I added some related patches, like introducing hooks when
 translation is changed (to rebuild package) or projects branching. I have
 other ideas for GP improvements but that’s blocked by lack of any
 development over there.

 == Conclusion ==

 I propose that core support for language packs lands early in 3.6 cycle.
 This would give enough time for testing and shift attention to
 !WordPress.org and GlotPress since they need a lot more changes.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18200#comment:43>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software