-
Notifications
You must be signed in to change notification settings - Fork 63
Add migration notice and translation banner to the blank layout; fix translation banner logic #904
Conversation
Add MigrationNotice and TranslationBanner to the blank layout
# Conflicts: # src/components/VMigrationNotice.vue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Works well. Just a couple non-blocking comments. Glad we can fix this 🎉
Should we also create a follow-up issue to resolve once this and the theme updates are all deployed to remove any vestiges of the cookie based local stuff? For example I think en_US
might be redundant with en
in that check as we're never given the wpLocale
, just the slug from the theme.
src/composables/use-i18n-sync.js
Outdated
/** | ||
* Show banner inviting to contribute translations if fewer than 90% | ||
* of strings are translated for current locale. | ||
* Hard-coded to false for default locales: `en` and `en_US`. | ||
* | ||
* @param {import('../locales/scripts/types').i18nLocaleProps} locale - current locale object | ||
* @param {string} localeCode - the wpLocale code for the current locale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: It won't be the wp_locale
, it'd be the locale slug. wp_locale
refers to the en_US
, pt_BR
version. The slug is what we use 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually not a nit, as there are at least three pieces to each locale that are important here, and we should be sure to select the correct one.
In the wporg_locales.sql
you can see that each locale has locale
and subdomain
properties. locale
corresponds to the wp_locale
property in the valid-locales.json
file. This is different from the key (code
) that we use for the locale in Vue-i18n (valid-locales.json
file), and is the same as the slug
in the GlotPress list of locales where we originally take the data from. And that slug
, in turn, is different from the subdomain
that is used on WordPress.org.
This is really complicated, and all the values are just a little bit different from one another for some locales.
So, what does locale_slug
mean in this case, @sarayourfriend ? Is it the same as the subdomain
in the wporg_locales.sql
, or slug
from the (GlotPress list)[https://github.com/GlotPress/GlotPress-WP/blob/develop/locales/locales.php]?
You can see the difference if you check Venezuelan Spanish: it's wporg subdomain is ve
, slug in GllotPress is es-ve
, wpLocale is es_VE
, and the HTML lang code for it should be es-ve
(although ve.wordpress.org site uses es
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if you look at the GP_Locales
class in the locales
plugin for wp.org it's a little easier to see what I mean. wporg_locales.sql
I think just configures the subdomain -> wp_locale mapping.
There you can see that the string we use to match a <locale>.json
is the slug
property. get_locale()
in WordPress returns the wp_locale
property. That's why in the PR to update the wporg-openverse theme to forward the locale via the iframe path needed to map the wp_locale
to the slug
property.
The subdomain is totally separate. The Brazilian locale, for example, is subdomained at br.wordpress.org
, but the locale is pt_BR
and the slug is pt-br
. The subdomains that wp.org uses are really just kind of made up/convenient compared to the proper locale codes they map to. For example, the Brazilian br
subdomain actually clashes with the Breton locale code: https://github.com/wordpress/wordpress.org/blob/e38ba4261c11f90443116df4b2e0654410eb8c04/wordpress.org/public_html/wp-content/mu-plugins/pub/locales/locales.php#L410
Weird stuff! 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your detailed explanation!
We also use this slug
property to create the translate link, as in (https://translate.wordpress.org/locale/{slug}/default/meta/openverse/)
. When first writing the translation banner logic, I was afraid we would need the subdomain data as well somewhere. But if we only use slug, we can simplify the locale data object that we have :)
test/e2e/translation-banner.spec.js
Outdated
test('Can close the translation banner', async ({ page }) => { | ||
await page.goto('/ru/search/') | ||
await page.click('[aria-label="Закрыть"]') | ||
|
||
const banner = page.locator( | ||
'text=The translation for Russian locale is incomplete. Help us get to 100 percent by ' | ||
) | ||
await expect(banner).not.toBeVisible({ timeout: 10 }) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe one more test to verify that the banner is automatically hidden on subsequent page loads after dismissal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. On the home and 404 pages these elements cause the height of the page to exceed 100vh, but I think that's okay.
I'll make separate issues, but both banners enabled is not particularly attractive (cc @panchovm):
The translation banner styles aren't ideal on mobile, I think it can be made smaller with some adjustment.
Both banners enabled looks pretty ugly, honestly:
I will work on both banners to match the WP.org style. Thanks @obulat for the work and @zackkrida for tagging me |
Fixes
Fixes #784 by @zackkrida
Description
This PR:
Testing Instructions
Run the app and go to
http://localhost:8443/ru/
. You should be able to see the translation banner at the top. From there, you can go to the Russian Openverse translation page, or close the banner. If you navigate to other pages, you should not see the banner after closing it once. Also, you shouldn't see the banner athttp://localhost:8443
.Checklist
Update index.md
).main
) or a parent feature branch.Developer Certificate of Origin
Developer Certificate of Origin