Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use gutenberg translation files locally #536

Merged
merged 36 commits into from
Feb 21, 2019
Merged

Use gutenberg translation files locally #536

merged 36 commits into from
Feb 21, 2019

Conversation

Tug
Copy link
Contributor

@Tug Tug commented Feb 4, 2019

Addresses part of #203
Requires wordpress-mobile/WordPress-Android#9249
Requires wordpress-mobile/WordPress-iOS#11056

Requires those 2 PRs to be merged first so the gb-mobile strings get translated in WPiOS and WPAndroid glotpress:
wordpress-mobile/WordPress-iOS#10999
wordpress-mobile/WordPress-Android#9214

Summary

This PR adds a local script that downloads gutenberg translation files and cache them locally.

Testing Instructions

  • Load this branch locally

  • Run yarn start and check that translation files are downloaded in i18n-cache/data and that a file is generated at i18n-cache/index.native.js

  • Edit src/app/App.js and replace setLocaleData( getTranslation( locale ) ); with setLocaleData( getTranslation( 'es' ) );

  • Reload the app and check that parts of the app have been translated to Spanish

  • Reset the code and run yarn wpandroid or yarn ios

  • Change the app or the phone language

  • Check that gutenberg editor is translated

A PR in both https://github.com/wordpress-mobile/WordPress-iOS and https://github.com/wordpress-mobile/WordPress-Android will be necessary to pass the new locale parameter.

@Tug Tug requested a review from hypest February 5, 2019 14:06
@koke koke mentioned this pull request Feb 14, 2019
'tr', // Turkish
'zh-cn', // Chinese (China)
'zh-tw', // Chinese (Taiwan)
];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, can we add el too? I'm biased :P

src/app/App.js Outdated
@@ -1,31 +1,63 @@
/** @flow
* @format */

import '../globals';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to import globals here too? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't be required, removing it 👍

src/app/App.js Outdated
};
setLocale( locale: ?string ) {
const translationsFromParentApp = this.props.translations || {};
const translations = Object.assign( {}, translationsFromParentApp, getTranslation( locale ) );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I'm thinking, how about giving the WP apps priority here? Like, if there's a conflict between what the parent sends and what Gutenberg has then let's give the parent priority. That would also give us the ability to have each mobile platform decide to overwrite a string, for whatever reason (e.g. platform guidelines). WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds sane. The only thing I'm afraid of though is mixing english and an other language in the case of using a language which is supported by the app but not by gutenberg for instance.

If you don't think it's a problem I can give the parent app priority

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, won't that be true the other way too? Like, if some strings are translated by GB but the native specific ones are not, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I went with your approach in the end and decided to mix both and give priority to the parent app 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All in all, I think that giving priority to the native side strings should be a good start. We can revise if we see it be problematic.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the current Spanish translations in both apps and Gutenberg for common strings, and everything seems pretty consistent. The only difference I've spotted that's perhaps relevant is how media library is translated, and it makes sense that we're consistent with the app translation, so good call 😁

@pinarol pinarol requested a review from etoledom February 21, 2019 14:27
@pinarol
Copy link
Contributor

pinarol commented Feb 21, 2019

hey @etoledom 👋 it'd be ok if you just review the iOS bridge and iOS example app changes

Copy link
Contributor

@etoledom etoledom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The iOS part looks good on the example app! ✅

@@ -116,6 +116,15 @@ extension GutenbergViewController: GutenbergBridgeDelegate {
}

extension GutenbergViewController: GutenbergBridgeDataSource {

func gutenbergLocale() -> String? {
return "en"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could send the device locale directly. Since is the example app is not a blocker, but it would nice to test translations just by changing the device language in the run settings for fast tests.

Suggested change
return "en"
return Locale.preferredLanguages.first ?? "en"

Copy link
Contributor

@pinarol pinarol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Contributor

@hypest hypest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@hypest
Copy link
Contributor

hypest commented Feb 21, 2019

Even though this PR is ready to merge, please don't merge until the PRs in the parent apps are also ready to merge. cc @Tug @pinarol @koke

@koke koke merged commit a24a46c into develop Feb 21, 2019
@koke koke deleted the add/i18n-cache branch February 21, 2019 21:01
@koke koke restored the add/i18n-cache branch February 21, 2019 21:02
@koke koke deleted the add/i18n-cache branch February 21, 2019 21:02
@koke
Copy link
Member

koke commented Feb 21, 2019

When I run yarn install I'm seeing this

Could not find translation file https://widgets.wp.com/languages/gutenberg/en-ca.json
Could not find translation file https://widgets.wp.com/languages/gutenberg/en-au.json
Could not find translation file https://widgets.wp.com/languages/gutenberg/nb.json

Is that expected?

@koke koke mentioned this pull request Feb 21, 2019
@hypest
Copy link
Contributor

hypest commented Feb 21, 2019

Yes, I think I remember @Tug mentioning this to me on a voice chat that not all locales supported by the apps (where the original list of locales came from) are supported by Gutenberg @koke .

koke added a commit to wordpress-mobile/WordPress-iOS that referenced this pull request Feb 21, 2019
@koke
Copy link
Member

koke commented Feb 21, 2019

I was mentioning this to Tug on slack, that Norwegian seems to be on Glotpress so maybe this is more of a WordPress.com think. It might be a good idea to switch to fetching from glotpress directly before the release. This seems to download translations but I haven't tested if it's the same JSON format:

curl "https://translate.wordpress.org/projects/wp-plugins/gutenberg/dev/nb/default/export-translations?format=json"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants