i18n: Use translations for theme name, content, terms, and page title

[ryelle]

Fixes #74. This uses the theme object content for themes, which should automatically use the localized theme name and description.

Additionally, I've added the in-progress i18n composite action (https://github.com/WordPress/wporg-repo-tools/pull/31), which pulls down term and page titles so that they can be easily imported into GlotPress with the rest of the strings (this is the generated commit https://github.com/WordPress/wporg-theme-directory/commit/4e7830446f5aa21abdec8f7f8f9e9fbc85d5df9f). As this theme is not being parsed yet, this doesn't do anything, but once it's indexed it should expose those items for translation so that, for example, "Commercially Supported GPL Themes" in the local nav can be translated.

The translation code was pulled from pattern-translations.

Screenshots

The theme title & description are translated. The "Features" list will be translated once the project is in GlotPress (and translated).

Before	After

How to test the changes in this Pull Request:

1. Using a sandbox, view a popular theme (more likely it will have translations)
2. The title and content should appear translated

You can also test the page name and term name translations with Pig Latin, just disable the en_US check in translate_term. You'll see some errors about the font_subset though.

[dd32]

Hmm actually..

Most of the Filter tags were intended to inherit their translations from Core, I don't recall if this is strictly required to match though.. I imagine not, as I assume it's query-by-slugs.

See https://github.com/WordPress/wordpress.org/blob/be52df3852af42a93c61377aa897b3ca59d51670/wordpress.org/public_html/wp-content/plugins/theme-directory/class-themes-api.php#L254-L405

Which originally matched the strings available here: https://github.com/WordPress/wordpress-develop/blob/4e244424f0ab69dd4ddf809567453927b412385d/src/wp-admin/includes/theme.php#L314-L362 https://github.com/WordPress/wordpress-develop/blob/4e244424f0ab69dd4ddf809567453927b412385d/src/wp-includes/class-wp-theme.php#L1067-L1090

[ryelle]

Yeah, I saw the hardcoded filter list (it's also been copied into the theme, since wporg_themes_query_api( 'feature_list' ) would only return slugs). It sounds like I should remove the textdomain there, if it's meant to inherit from core.

I suppose for tags I could pull from that list of translations instead of generating a duplicate list in translation-strings.php.

[ryelle]

oops, this also applies to the pagination links:

[ryelle]

Okay, I've fixed the pagination bug and updated the tag translation to use the features list (and omitted tags from the string export). However, I realized this doesn't match core 100% because I've switched the strings to use sentence-case. So the list is back to using wporg-themes textdomain. It seems like it would be fine to use a slightly different list, since the slugs are the same.