[wp-meta] [Making WordPress.org] #1691: Internationalisation

[Making WordPress.org]

#1691: Internationalisation
------------------------------+------------------
 Reporter:  dd32              |       Owner:
     Type:  task              |      Status:  new
 Priority:  high              |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+------------------

Comment (by ocean90):

 '''Let's start with status quo:'''

 * We have four systems: bbPress, SVN tracker, WordPress with GlotPress,
 and Slack.
         * bbPress inits the SVN tracker.
         * SVN tracker checks revision numbers starts the build process, on
 each web node (5)
         * web1 takes care of updating the data in bbPress and that's where
 the i18n process is hooked into too.
 * The i18n process is split into two parts: `process_code` and
 `process_readme`
         * `process_readme` runs if the changeset includes a change to a
 readme file.
         * `process_code` runs if the changeset includes more than a readme
 change.
         * If a changeset includes both then both processes (code first)
 run.
 * In GlotPress we have four projects for each plugin:
         * `dev` - Code project for trunk
         * `stable` - Code project for the `stable_tag`
         * `dev-readme` - Redme project for the readme.(md|txt) in trunk
         * `stable-readme` - Readme project for the readme.(md|txt) in
 `stable_tag`
 * The i18n process is smart enough to only update the `dev` project when
 something was changed in the trunk directory.
 * For the rest of the import see [attachment:plugin-import.jpeg].
 * For the front end we have several caches which is the reasons why none
 of the translated data is searchable. The graphic [attachment:plugin-
 front-end.jpeg] makes this clear.
 * Changes to readme translations are live immediately.

 '''The future:'''

 Both graphics include some ⚠️ for a few steps. These should be resolved
 with the new directory. The front end has the biggest one. Some ideas on
 how we could solve this:

 * Store translated data in '''post meta''':
   * For example `title_de_DE` holds the title in German,
 `short_description_it_IT` holds the short description in Italian. But that
 doesn't scale well IMO. We've around 70 active locales but the system
 should be designed to work with all locales, ~170 currently.
   * Let's say we have 5 meta fields: 170x5 = 850 fields for one plugin.
 850 * 44k plugins = too many. ;-)
 * Store translated data in another '''post type''':
   * For example the post type `plugin_de_de` includes all the translated
 data into German. (Note: The name of a post type is limited to 20 chars.
 Maybe use an ID instead: `plugin_1` with `1` = `de_DE` or `plugin_2` with
 `2` = `de_DE_formal`.)
   * For the relationship we can use Post 2 Post.
   * Using a post type doesn't require to do bulk updates like mentioned in
 #1692 and fits with the idea to have something like `content_de`.

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