feat: support Spanish emojis#20828
Conversation
|
@0xmiroslav Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
| QUICK_REACTIONS: [ | ||
| { | ||
| name: '+1', | ||
| shortcode: {en: '+1', es: '+1'}, |
There was a problem hiding this comment.
Can you stick to original structure? I don't see any reason why name should be changed to shortcode
There was a problem hiding this comment.
This is for clarity. They are not names of emojis, just short codes of them. I mentioned this in issue before
There was a problem hiding this comment.
Strictly, they are "short name", not code.
If I follow you, code = '😄', short code = 'smile',
Why code length should be smaller than short code length?
As we don't support name for now, we can just use name instead of short name.
So let's keep original structure.
There was a problem hiding this comment.
I think that the name should always be in english. In the database we save the reactions like this:
{"emoji":"heart","users":[{"accountID":8505565,"skinTone":-1}...]
If we start changing that then you would be able to react with the same emoji in both english and spanish.
| shortcode: {en: '+1', es: '+1'}, | ||
| code: '👍', | ||
| types: ['👍🏿', '👍🏾', '👍🏽', '👍🏼', '👍🏻'], | ||
| types: ['👍🏻', '👍🏼', '👍🏽', '👍🏾', '👍🏿'], |
There was a problem hiding this comment.
NAB but why orders changed?
There was a problem hiding this comment.
I am also confused. As far as I can tell the types are already displayed in that order, so I don't understand why we need to change this
There was a problem hiding this comment.
As you can see below, skintone numbering is weird. I think this change is reasonable.
Lines 56 to 81 in 83ab016
There was a problem hiding this comment.
Please make sure that this order change doesn't cause any regressions even if it's minor.
| headerEmojis: PropTypes.arrayOf( | ||
| PropTypes.shape({ | ||
| code: PropTypes.string.isRequired, | ||
| name: PropTypes.string.isRequired, |
There was a problem hiding this comment.
Same here. I don't see any reason of code -> name
There was a problem hiding this comment.
Headers has no code unlike emojis. It has only name and icon. I wanted to add meanings to the properties
There was a problem hiding this comment.
We already have localized strings here:
Lines 1221 to 1233 in edf529e
We can still use frequentlyUsed, etc for code.
There was a problem hiding this comment.
I'll change the headers back to original Spanish.
But let's keep the current emoji data structure as is. We have all Spanish emojis in its own structure, and we treat headers as emojis as well. Why don't we translate headers in the same place? I don't understand why headers should be in en/es.js. We can safely remove all emojis from en/es.js. This is more clear and reasonable, I think.
There was a problem hiding this comment.
@stitesExpensify do you agree with this new structure?
There was a problem hiding this comment.
I think we should think about extension of supported languages, not about original structure.
There was a problem hiding this comment.
I'm confused @s-alves10 what is the benefit of this change? In the future we're going to add other files like de.js which with have german translations etc. for the whole app, so it seems like keeping the current structure makes more sense than changing it
0xmiroslav
left a comment
There was a problem hiding this comment.
Your updated structure of name -> shortcode, header code -> name can be follow-up if needed.
In this PR, let's reduce code diff as much as possible and try to keep original structure but just add localization.
| QUICK_REACTIONS: [ | ||
| { | ||
| name: '+1', | ||
| shortcode: {en: '+1', es: '+1'}, |
There was a problem hiding this comment.
Strictly, they are "short name", not code.
If I follow you, code = '😄', short code = 'smile',
Why code length should be smaller than short code length?
As we don't support name for now, we can just use name instead of short name.
So let's keep original structure.
| headerEmojis: PropTypes.arrayOf( | ||
| PropTypes.shape({ | ||
| code: PropTypes.string.isRequired, | ||
| name: PropTypes.string.isRequired, |
There was a problem hiding this comment.
We already have localized strings here:
Lines 1221 to 1233 in edf529e
We can still use frequentlyUsed, etc for code.
stitesExpensify
left a comment
There was a problem hiding this comment.
I'm a bit confused about some of these changes. I was under the impression that we were just adding spanish keywords to the file, and creating a spanish Trie. If you could clarify why other changes were necessary that would be great @s-alves10
| shortcode: {en: '+1', es: '+1'}, | ||
| code: '👍', | ||
| types: ['👍🏿', '👍🏾', '👍🏽', '👍🏼', '👍🏻'], | ||
| types: ['👍🏻', '👍🏼', '👍🏽', '👍🏾', '👍🏿'], |
There was a problem hiding this comment.
I am also confused. As far as I can tell the types are already displayed in that order, so I don't understand why we need to change this
| QUICK_REACTIONS: [ | ||
| { | ||
| name: '+1', | ||
| shortcode: {en: '+1', es: '+1'}, |
There was a problem hiding this comment.
I think that the name should always be in english. In the database we save the reactions like this:
{"emoji":"heart","users":[{"accountID":8505565,"skinTone":-1}...]
If we start changing that then you would be able to react with the same emoji in both english and spanish.
| headerEmojis: PropTypes.arrayOf( | ||
| PropTypes.shape({ | ||
| code: PropTypes.string.isRequired, | ||
| name: PropTypes.string.isRequired, |
There was a problem hiding this comment.
I'm confused @s-alves10 what is the benefit of this change? In the future we're going to add other files like de.js which with have german translations etc. for the whole app, so it seems like keeping the current structure makes more sense than changing it
|
Thank you for your feedback Emojis have its own data structure supporting multiple languages.
|
I am not opposed your suggestion but this was what I suggested. @stitesExpensify what do you suggest? |
|
I agree. I don't think that we need to make such big changes in this PR. All we really want from this PR is for typing |
|
@s-alves10 lint failing. Please make sure to test all possible cases. Though I already tested, there might still be any missing case. |
|
Will you take a look at the PR again? |
|
It's US holiday today. Let's wait one more day |
|
Hi there! Taking a look! |
|
@s-alves10 please fix conflict |
stitesExpensify
left a comment
There was a problem hiding this comment.
Code is looking great! Just a couple of small questions before I approve
|
Please take a look at the changes. Thank you |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/stitesExpensify in version: 1.3.39-0 🚀
|
|
🚀 Deployed to production by https://github.com/francoisl in version: 1.3.39-11 🚀
|
|
Just coming from this issue that fixed a bug that this PR introduced that caused duplicate suggestions to appear. Since we add the English Trie node with the suggestion's name in English, this won't match the equivalent Spanish emoji name, so it gets added as a separate match here: Line 381 in 3f9f1e6 |



Details
Fixed Issues
$ #16086
PROPOSAL: #16086 (comment)
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Web
16086_mac_chrome.mp4
Mobile Web - Chrome
16086_anrdoid_chrome.mp4
Mobile Web - Safari
16086_ios_safari.mp4
Desktop
16086_mac_desktop.mp4
iOS
16086_ios_native.mp4
Android
16086_anroid_native.mp4