[wp-meta] [Making WordPress.org] #6188: Language Pack generation: trigger on plugin update

[Making WordPress.org]

#6188: Language Pack generation: trigger on plugin update
--------------------------------------+---------------------
 Reporter:  adamsilverstein           |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:
Component:  Translate Site & Plugins  |  Resolution:
 Keywords:                            |
--------------------------------------+---------------------

Comment (by dd32):

 > Would it be possible to have translations packs also regenerated for
 each plugin version update?

 My understanding is that this already happens, but that it doesn't happen
 immediately at plugin update.

 For example, I see that Site Kit 1.70.0 was released at `2022-03-14
 19:23`, and the language packs were generated at `2022-03-14 20:08`.
 For Site Kit 1.69.0, released at `2022-02-28 19:33` first language packs
 built at `2022-02-28 20:18`.

 We may be able to decrease this delay for tagged releases, as it's
 primarily delayed (AFAIK) for plugins which make multiple commits to trunk
 in a row / commit to trunk and then commit to tags a few minutes later.
 Ideally we'd delay the plugin update until the language pack is built, but
 that's not always a viable solution.

 There's a delay between the language pack being built, and when it's
 installed on the site as well, which could be upwards of 24hrs depending
 on the site, or even delayed until the next time they manually install a
 plugin if the site doesn't have write access to the language files.

 > If this would consume excessive resources as a default, maybe it could
 be an opt-in behavior, with a header option for "auto-regeneration", or
 perhaps a "translation version" string that when changed would trigger an
 update?

 Not required, We can detect this based on the string references changing,
 but instead we simply rebuild them for each plugin version it appears.

 > Site Kit uses hashed names for our JavaScript files, we found that
 without this users would get JavaScript errors after upgrades due to
 cached JS in their browsers (despite versioning the script tag).

 While this makes zero sense.. it sounds like an issue related to
 filesystem caching, This sounds like a hosting issue rather than a plugin
 issue.. as WordPress would be running into the same issue with every
 plugin and core CSS/JS file.
 Nevertheless, this is a choice for the plugin to make, and we don't
 require you to keep file references consistent.

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