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

3770 multi language improvements #4134

Merged
merged 16 commits into from
Jul 27, 2021

Conversation

dklymenk
Copy link
Contributor

@dklymenk dklymenk commented Jul 18, 2021

Details

This PR makes these changes:

  1. Hide all the locale switching functionality if user doesn't have internationalization beta.
  2. Move locale selector from preferences page into a separate component LocalePicker so it can be reused across the app.
  3. Add LocalePicker to sign in page's footer.
  4. Small footer redesign according to this figma .
  5. Selected locale preference persists through logout.

Fixed Issues

$ #3770

Tests

  1. While logged in, navigate to preferences page and change language to Spanish.
  2. Log out.
  3. Verify that the language is still Spanish.
  4. Verify that selecting English in the new language selector at the footer, correctly changes the app language.

QA Steps

  1. Verify that there is no language selector on preferences page
  2. Log out
  3. Verify that there is no language selector on sign-in page's footer.

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web

3770-web.mp4

Mobile Web

Simulator.Screen.Recording.-.iPhone.12.-.2021-07-21.at.15.07.17.mp4

Desktop

Screen.Recording.2021-07-21.at.15.01.01.mov

iOS

Simulator.Screen.Recording.-.iPhone.12.-.2021-07-21.at.15.10.28.mp4

Android

3770-android.mp4

@github-actions
Copy link
Contributor

github-actions bot commented Jul 20, 2021

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

@dklymenk dklymenk marked this pull request as ready for review July 21, 2021 12:30
@dklymenk dklymenk requested a review from a team as a code owner July 21, 2021 12:30
@MelvinBot MelvinBot requested review from madmax330 and removed request for a team July 21, 2021 12:30
@dklymenk
Copy link
Contributor Author

dklymenk commented Jul 21, 2021

I've added a change that makes the legal text aligned to the left as suggested by figma.

Here are some relevant screenshots:
web
DeepinScreenshot_select-area_20210721184805

android
DeepinScreenshot_select-area_20210721184814

ios
Screen Shot 2021-07-21 at 19 14 10

@shawnborton
Copy link
Contributor

Looks great!

@@ -13,6 +13,7 @@ import Clipboard from '../../../assets/images/clipboard.svg';
import Close from '../../../assets/images/close.svg';
import CreditCard from '../../../assets/images/creditcard.svg';
import DownArrow from '../../../assets/images/down.svg';
import DownArrowSmall from '../../../assets/images/down-small.svg';
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think you actually need a new asset for this. Why not just use the existing down arrow and just resize it to 12x12? That's what we have in the Figma file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. I have removed the new asset and now reusing the old one in the latest commit.

Thanks.

Copy link
Contributor

@madmax330 madmax330 left a comment

Choose a reason for hiding this comment

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

Looks good, just a couple of small comments I would like resolved before merging

{size === 'small'
? (
<Icon
width={12}
Copy link
Contributor

Choose a reason for hiding this comment

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

@shawnborton should we set constants for these?

Copy link
Contributor

Choose a reason for hiding this comment

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

Or should they be in the pickerstyles?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 I think we put all styles inthe styles file, no?

Copy link
Contributor

Choose a reason for hiding this comment

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

Also why we need this conditional, shouldn't that be handled here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

should we set constants for these?

added styles.pickerSmall.icon.{width,heigth} and now using those instead of hardcoded values

Also why we need this conditional, shouldn't that be handled here?

Since this Picker component supports overwriting the Icon component via props and this is not a required prop, the default implementation for it is in Picker/PickerPropTypes.js. If we were do this logic in Picker/index.js we kinda have to ditch the icon prop entirely since it will be overwritten inside the component anyway. I too feel like it doesn't look good, but don't know if we can do it cleaner. Maybe we should indeed drop support for icon overwrite since it doesn't seem to be used, but I think we should look into why it was implemented like that in the first place, maybe it is required for some future feature?

const localesToLanguages = {
default: {
value: 'en',
label: translate('preferencesPage.languages.english'),
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should keep the language name labels in their original Language. So English would always be "English" spanish will always be "Espagnol" and so on.
Otherwise say someone changes my app to chinese (or I do by accident) I'm going to have a tough time getting it back to english.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I think I agree.
So maybe what we want to do is:

  • Add a translation for languageName that we add to each translation file
  • Do not use the translate method from withLocalize here (but we do want to use it for the label in line 55) and instead use the translate method directly from the translate file
  • Pass the as 1st param the locale of the item we are showing (ie: 'en' here and 'es' below)

That way, we ensure we have one language name per language and that each language name shows in their own language.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I totally agree, I too get into this kinda situation from time to time.

@iwiznia I have implemented the change, but I completely missed the idea behind your first point. Please take a look at the current version of code and let me know if there is something to be added.

Thanks.

@@ -0,0 +1,86 @@
import React from 'react';
Copy link
Contributor

Choose a reason for hiding this comment

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

Commenting here because I can't comment on the file name itself. I think this file should be src/components/LocalePicker.js, no? Since we only have one version of it, we don't need the folder, 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.

You're right. I have moved components/LocalePicker/index.js to components/LocalePicker.js. Thanks.

const localesToLanguages = {
default: {
value: 'en',
label: translate('preferencesPage.languages.english'),
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I think I agree.
So maybe what we want to do is:

  • Add a translation for languageName that we add to each translation file
  • Do not use the translate method from withLocalize here (but we do want to use it for the label in line 55) and instead use the translate method directly from the translate file
  • Pass the as 1st param the locale of the item we are showing (ie: 'en' here and 'es' below)

That way, we ensure we have one language name per language and that each language name shows in their own language.

},
es: {
value: 'es',
label: translate('preferencesPage.languages.spanish'),
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
label: translate('preferencesPage.languages.spanish'),
label: translate('preferencesPage.languages.es'),

Same for the above

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, but I'm confused about this one. Do you want me to change the translation keys for languages to be their 2 letter code instead of full language name (spanish -> es, english -> en)? I thought your point about es and en was to pass them as first argument to the translate function.

return (
<>
{size === 'normal' && (
<Text style={[styles.formLabel]} numberOfLines={1}>
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
<Text style={[styles.formLabel]} numberOfLines={1}>
<Text style={[styles.formLabel]} numberOfLines=1>

Is this valid and equivalent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, a JSX value should be either an expression or a quoted JSX text.

{size === 'small'
? (
<Icon
width={12}
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 I think we put all styles inthe styles file, no?

{size === 'small'
? (
<Icon
width={12}
Copy link
Contributor

Choose a reason for hiding this comment

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

Also why we need this conditional, shouldn't that be handled here?

@madmax330 madmax330 merged commit 0e5e46a into Expensify:main Jul 27, 2021
@OSBotify
Copy link
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@OSBotify
Copy link
Contributor

🚀 Deployed to staging in version: 1.0.80-3🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@marcaaron marcaaron mentioned this pull request Jul 28, 2021
5 tasks
@iwiznia
Copy link
Contributor

iwiznia commented Jul 29, 2021

This was broken and fixed here #4286 thought it is possible the problem came from other PRs written while this was being reviewed.

@OSBotify
Copy link
Contributor

🚀 Deployed to production in version: 1.0.81-4🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

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

Successfully merging this pull request may close these issues.

5 participants