feat: Translations #1322
feat: Translations #1322
Conversation
Cleaned up most non-translated strings Added French
WalkthroughThe pull request introduces localization enhancements across multiple components in the application. It replaces hardcoded strings with calls to a Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Performance Comparison ReportSignificant Changes To DurationThere are no entries Meaningless Changes To DurationShow entries
Show details
Render Count ChangesThere are no entries Render IssuesThere are no entries Added ScenariosThere are no entries Removed ScenariosThere are no entries |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (16)
i18n/i18n.ts (1)
7-7: Consider adding translation key validationThe French translations are correctly imported and configured. However, to ensure maintenance reliability, consider adding runtime or build-time validation to ensure all translation keys are present across all language files.
Would you like me to provide an implementation for a translation key validator that can be run during the build process?
Also applies to: 17-17
screens/NewConversation/NewConversationModal.tsx (1)
54-55: Consider error handling for conditional translationsThe conditional translation might fail if either translation key is missing. Consider adding fallbacks and error handling.
- ? translate("new_group.add_members") - : translate("new_conversation.new_conversation") + ? translate("new_group.add_members", "Add Members") + : translate("new_conversation.new_conversation", "New Conversation")screens/TopUp.tsx (1)
Line range hint
44-44: Translate the "Cancel" button textThe "Cancel" button text is still hardcoded. Consider using a translation key for consistency.
- title="Cancel" + title={translate("common.cancel")}components/DebugButton.tsx (2)
Line range hint
71-71: Translate remaining alert messagesSeveral alert messages are still hardcoded. Consider using translation keys for consistency.
- alert("No new update"); + alert(translate("debug.no_update")); - alert("Done!"); + alert(translate("common.done")); - alert("Done!"); + alert(translate("common.done")); - return Alert.alert("No previous session logging file found"); + return Alert.alert(translate("debug.no_previous_logs")); - return Alert.alert("No previous session logging file found"); + return Alert.alert(translate("debug.no_previous_logs"));Also applies to: 89-89, 97-97, 123-123, 142-142
Line range hint
82-82: Consider translating the test error messageWhile this is a debug/test error message, it should be translated for consistency with the rest of the application.
- throw new Error("My first Sentry error!"); + throw new Error(translate("debug.test_error"));containers/GroupScreenMembersTable.tsx (1)
116-116: Consider consolidating error handling logic.While the error handling with
captureErrorWithFriendlyToastis good, the pattern is repeated across multiple catch blocks. Consider extracting this into a higher-order function to reduce code duplication.+ const handleMemberActionError = async (action: () => Promise<void>) => { + try { + await action(); + } catch (e) { + logger.error(e); + captureErrorWithFriendlyToast(e); + } + }; // Usage example: - try { - await promoteToSuperAdmin(a.inboxId); - } catch (e) { - logger.error(e); - captureErrorWithFriendlyToast(e); - } + await handleMemberActionError(() => promoteToSuperAdmin(a.inboxId));Also applies to: 125-125, 134-134, 143-143, 152-152
screens/ConversationList.tsx (1)
203-205: Consider using context-specific translation keysWhile using the same translation key 'conversation_list.messages' works, consider using more specific keys for different UI contexts (search title vs. header title) to allow for context-specific translations in some languages.
- {translate("conversation_list.messages")} + {translate("conversation_list.search_title")} // And for header - {translate("conversation_list.messages")} + {translate("conversation_list.header_title")}Also applies to: 211-213, 220-222
screens/NewConversation/NewGroupSummary.tsx (2)
281-281: Verify translation key hierarchy consistencyThe translation keys use different hierarchical structures:
members_title(flat)new_group.add_members(nested)new_group.edit_group_info(nested)new_group.members_can(nested)Consider standardizing all group-related keys under the
new_groupnamespace.- title={translate("members_title")} + title={translate("new_group.members_title")}Also applies to: 286-286, 296-296, 306-306
Line range hint
286-306: Consider adding aria-labels for accessibilityThe permission switches would benefit from translated aria-labels to improve accessibility.
rightView: ( <Switch + accessibilityLabel={translate("new_group.toggle_add_members")} onValueChange={handlePermissionSwitch("addMembers")} value={permissionPolicySet.addMemberPolicy === "allow"} />i18n/translations/en.ts (2)
325-330: Consider consolidating related translation keys.The
new_groupandnew_conversationsections have similar keys. Consider creating a shared namespace for common actions to improve maintainability.Example restructuring:
- new_group: { - add_members: "Add members", - edit_group_info: "Edit group info", - members_can: "MEMBERS CAN", - }, - new_conversation: { - create_group: "Create group", - back: "Back", - create: "Create", - add_members: "Add members", - new_conversation: "New conversation", - invite_to_converse: "Invite them to Converse", - }, + common: { + back: "Back", + create: "Create", + add_members: "Add members", + }, + new_group: { + edit_group_info: "Edit group info", + members_can: "MEMBERS CAN", + }, + new_conversation: { + create_group: "Create group", + new_conversation: "New conversation", + invite_to_converse: "Invite them to Converse", + },Also applies to: 332-337
460-464: Ensure consistent formatting for multi-line strings.Some multi-line strings use different line-breaking approaches. Consider standardizing the format for better maintainability.
Also applies to: 470-474, 476-480
i18n/translations/fr.ts (2)
488-493: Consider French-specific grammar adjustments for placeholders.In French, some placeholder variables might need different surrounding spaces or punctuation. For example, in the recommendations section, the concatenation might need adjustment for French grammar rules.
Consider this adjustment:
- no_recommendations: - "Nous n'avons trouvé personne à vous suggérer. Nous sommes encore en phase précoce et n'utilisons pas encore beaucoup de signaux. Vous pouvez ", - signal_list: "trouver la liste actuelle ici", - please_feel_free_to: ", n'hésitez pas à ", - contact_pol: "contacter notre co-fondateur Pol", + no_recommendations: + "Nous n'avons trouvé personne à vous suggérer. Nous sommes encore en phase précoce et n'utilisons pas encore beaucoup de signaux. Vous pouvez", + signal_list: " trouver la liste actuelle ici", + please_feel_free_to: ". N'hésitez pas à", + contact_pol: " contacter notre co-fondateur Pol",
499-504: Standardize quotation marks usage.Some translations use different types of quotation marks. Consider standardizing them across the file.
screens/Profile.tsx (3)
302-302: Maintain consistent translation key naming convention.The translation keys use mixed naming conventions. Some keys use underscores (e.g.,
your_balance_usdc,top_up_your_account), while others use different patterns. Consider standardizing all translation keys to use underscores for better maintainability.Also applies to: 332-332, 523-523, 530-530, 531-531, 550-550, 556-556, 582-582, 588-588, 651-651, 845-845
Line range hint
775-785: Enhance error handling and user feedback.Consider improving the error handling in the following areas:
- Add specific error messages for different notification permission scenarios
- Implement comprehensive error feedback for the disconnect action
- Consider adding retry mechanisms for failed operations
- // TODO: Show error feedback to user + Alert.alert( + translate("error_title"), + translate("error_description", { error: error.message }) + );Also applies to: 845-855
Line range hint
619-651: Consider decomposing the component for better maintainability.The
ProfileScreenImplcomponent is quite large and handles multiple responsibilities. Consider:
- Extracting the social items logic into a separate component
- Creating a dedicated component for the action items
- Moving the table view sections into individual components
Example structure:
// components/Profile/ProfileSocials.tsx const ProfileSocials: React.FC<ProfileSocialsProps> = ({ socials }) => { // Social items logic }; // components/Profile/ProfileActions.tsx const ProfileActions: React.FC<ProfileActionsProps> = ({ isMyProfile }) => { // Action items logic };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (25)
components/Chat/Message/message-content-types/message-static-attachment.tsx(2 hunks)components/DebugButton.tsx(4 hunks)components/EphemeralAccountBanner.tsx(2 hunks)components/InitialLoad.tsx(2 hunks)components/Recommendations/Recommendations.tsx(4 hunks)containers/GroupScreenMembersTable.tsx(8 hunks)i18n/i18n.ts(1 hunks)i18n/translations/en.ts(5 hunks)i18n/translations/fr.ts(1 hunks)screens/Accounts/Accounts.tsx(2 hunks)screens/ConversationList.tsx(2 hunks)screens/Navigation/ConversationRequestsListNav.tsx(1 hunks)screens/Navigation/ConverseMatchMakerNav.tsx(2 hunks)screens/Navigation/GroupNav.tsx(2 hunks)screens/Navigation/Navigation.tsx(4 hunks)screens/Navigation/NewConversationNav.tsx(2 hunks)screens/Navigation/ShareFrameNav.tsx(2 hunks)screens/Navigation/TopUpNav.tsx(2 hunks)screens/Navigation/UserProfileNav.tsx(2 hunks)screens/Navigation/WebviewPreviewNav.tsx(2 hunks)screens/NewConversation/NewConversation.tsx(3 hunks)screens/NewConversation/NewConversationModal.tsx(3 hunks)screens/NewConversation/NewGroupSummary.tsx(5 hunks)screens/Profile.tsx(7 hunks)screens/TopUp.tsx(3 hunks)
🔇 Additional comments (23)
screens/Navigation/WebviewPreviewNav.tsx (1)
6-6: Consider consistent translation key hierarchy and URL parameter handling.
-
The translation key
file_previewcould follow the hierarchical pattern used elsewhere (e.g.,file_preview.header_title). -
Since this component handles URL parameters, consider future needs for translating query parameters or file names in the preview URL.
Let's verify the current translation key exists:
Also applies to: 29-29
screens/Navigation/GroupNav.tsx (1)
11-11: Standardize translation key format
The translation key "group_info" uses a different pattern (underscore) compared to other keys in the codebase that use dot notation (e.g., "profile.modify_profile"). Consider using a consistent format like "group.info" to maintain uniformity.
Let's verify the translation key exists and check for consistency:
Also applies to: 28-28
✅ Verification successful
Translation key format is consistent with existing patterns
Based on the search results, both formats (group_info and group.info) are actually used in the codebase:
- The flat key
group_infois used in base translations (en.ts, fr.ts) - The nested key pattern
new_group.edit_group_infois used for more specific features
The current usage of group_info in GroupNav.tsx matches the existing translation key in the i18n files, so no changes are needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for translation key definitions and usage patterns
rg -g '!*.{log,lock}' -A 1 "group_info|group.info"
# Look for translation files
fd -e json -e yaml -e yml . | grep -i "translation\|locale\|lang"
Length of output: 1310
screens/Navigation/ShareFrameNav.tsx (1)
19-19: 🛠️ Refactor suggestion
Localize the "Cancel" button text
While the header title has been localized, the "Cancel" button text remains hardcoded. This should also be translated for consistency.
Here's the suggested change:
<Button
- title="Cancel"
+ title={translate("common.cancel")}
onPress={() => {
navigation.goBack();
}}
/>Let's verify the suggested translation key exists:
Also applies to: 25-29
screens/Navigation/UserProfileNav.tsx (1)
12-12: LGTM! Clean translation implementation
The changes follow the proper translation pattern using dot notation and the implementation is clean.
Let's verify the translation key exists and is used consistently:
Also applies to: 23-23
✅ Verification successful
Translation key is correctly used and consistent
The verification shows that:
- The translation key "profile.modify_profile" is used consistently in both Navigation.tsx and UserProfileNav.tsx for the header title
- The usage is uniform across the codebase with no conflicting implementations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the translation key and similar patterns
rg -g '!*.{log,lock}' "profile\.modify_profile"
# Look for other profile-related translations to ensure consistency
rg -g '!*.{log,lock}' "profile\."
Length of output: 2476
screens/Navigation/NewConversationNav.tsx (2)
11-11: LGTM: Clean import of translation function
The translate import is correctly added from the i18n module.
31-31: Verify translation key existence and consider simplifying key name
The translation key "new_conversation.new_conversation" appears redundant. Consider simplifying to "new_conversation.title".
✅ Verification successful
Translation key is consistently used and follows established pattern
The translation key "new_conversation.new_conversation" is already in use across multiple files and is properly defined in both English and French translation files. While the key name appears redundant, changing it would require coordinated updates across several files:
- screens/Navigation/NewConversationNav.tsx
- screens/NewConversation/NewConversation.tsx
- screens/NewConversation/NewConversationModal.tsx
- i18n/translations/en.ts
- i18n/translations/fr.ts
The current naming follows a consistent pattern where the namespace matches the feature name. Simplifying it would deviate from this established pattern.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the translation key exists in both language files
echo "Checking translation key existence..."
rg -l "new_conversation\.new_conversation" i18n/translations/
Length of output: 148
Script:
#!/bin/bash
# Let's try to find translation files first
fd -t f . i18n/
# Then let's search for any files containing "new_conversation" to understand the translation structure
rg "new_conversation" -A 2 -B 2
Length of output: 4331
components/InitialLoad.tsx (2)
13-13: LGTM: Clean import of translation function
The translate import is correctly added from the i18n module.
26-27: LGTM: Well-structured translation implementation
The translation keys follow a clear hierarchical structure and maintain semantic meaning. The implementation preserves the original styling while making the text translatable.
i18n/i18n.ts (1)
Line range hint 20-33: LGTM: Robust locale fallback mechanism
The locale selection logic with fallback mechanism is well-implemented:
- Tries specific locale (e.g., en-US)
- Falls back to general locale (e.g., en)
- Ultimate fallback to en-US
components/EphemeralAccountBanner.tsx (1)
28-30: Verify translation key structure and add fallbacks
While the translation implementation looks correct, consider these improvements for robustness:
- Verify that the translation keys follow the established pattern across the codebase:
ephemeral_account_banner.titleephemeral_account_banner.subtitle
- Add fallback text for missing translations since this is important user-facing information.
Consider adding fallbacks:
- {translate("ephemeral_account_banner.title")}
+ {translate("ephemeral_account_banner.title", "Temporary Account")}
- {translate("ephemeral_account_banner.subtitle")}
+ {translate("ephemeral_account_banner.subtitle", "This is a temporary account. Your messages will be lost if you disconnect.")}Also applies to: 31-33
screens/NewConversation/NewConversationModal.tsx (1)
73-80: Verify translation namespace consistency
The translation keys use different namespaces ("new_group" and "new_conversation"). Verify this is intentional and consistent with the application's translation structure.
✅ Verification successful
Translation namespaces are consistently used across components
The codebase search reveals that both "new_conversation" and "new_group" namespaces are used intentionally and consistently:
- "new_conversation" namespace is used for general conversation creation UI elements and navigation
- "new_group" namespace is specifically used for group-related features like member management and group info editing
The different namespaces appear to be a deliberate separation of concerns between general conversation creation and group-specific functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check translation namespace consistency
# Look for other occurrences of these namespaces
rg "translate\([\"']new_(group|conversation)" --type ts --type tsx
# Check if these specific keys are defined in translation files
fd -e json -e yaml -e yml . | xargs rg "new_(group|conversation)\."
Length of output: 168
Script:
#!/bin/bash
# Search for translation keys in TypeScript files without specifying file extension
rg "translate\([\"']new_(group|conversation)"
# Find translation files and check their content
fd "translations|i18n|locale" -e json -e yaml -e yml | xargs cat
Length of output: 1481
components/Chat/Message/message-content-types/message-static-attachment.tsx (1)
5-5: LGTM! Translation key is appropriate
The error message has been properly internationalized using a descriptive translation key.
Also applies to: 88-88
screens/Navigation/ConversationRequestsListNav.tsx (1)
99-99: LGTM! Translation keys are well implemented.
The translation implementation for header titles is consistent and follows good practices.
containers/GroupScreenMembersTable.tsx (1)
76-76: LGTM! Well-structured translation keys.
The translation implementation for member roles and user indicators follows good naming conventions with proper namespacing.
Also applies to: 163-165, 168-170
components/Recommendations/Recommendations.tsx (1)
134-134: LGTM! Consistent translation namespace.
Good use of the "recommendations" namespace for all related strings, making the translations well-organized and maintainable.
Also applies to: 141-143, 193-195
screens/Navigation/Navigation.tsx (3)
108-108: LGTM: Back button translation implemented correctly
The translation key for the back button is appropriately generic, allowing for reuse across different screens.
189-189: LGTM: Profile modification header translation
The translation key 'profile.modify_profile' follows a hierarchical structure, which is a good practice for organizing translations.
268-268: LGTM: New account flow translations
The translation keys are consistently implemented across the new account navigation flow, covering back button, screen title, and modal actions.
Also applies to: 276-276, 279-279
screens/NewConversation/NewGroupSummary.tsx (1)
45-48: LGTM: Improved error handling with translations
Good improvement in error handling by replacing generic Alert with translated toast messages. The error capture utilities provide better error tracking and user feedback.
Also applies to: 137-139
screens/NewConversation/NewConversation.tsx (3)
49-49: LGTM! Import statement is correctly placed.
The translate function import is properly added at the top of the file.
107-109: LGTM! Header titles are properly internationalized.
The conditional header titles are correctly implemented using the translate function with appropriate translation keys.
465-465: LGTM! Invite text is properly internationalized.
The "Invite to Converse" text is correctly translated using the appropriate translation key.
screens/Profile.tsx (1)
529-532: LGTM: Well-implemented action sheets with proper platform handling.
The action sheet implementation correctly handles:
- Platform-specific styling
- Proper translation of options
- Consistent color schemes
- Appropriate cancellation and destructive actions
Also applies to: 556-565, 588-597
| @@ -3,6 +3,7 @@ import { useColorScheme } from "react-native"; | |||
|
|
|||
| import ConverseMatchMaker from "../ConverseMatchMaker"; | |||
| import { NativeStack, navigationAnimation } from "./Navigation"; | |||
| import { translate } from "@/i18n"; | |||
There was a problem hiding this comment.
💡 Codebase verification
Based on the extensive search results, I can see that there is indeed a consistent pattern of using hierarchical translation keys throughout the codebase. Examples include:
top_up.header_titleuserProfile.buttons.continueprivyConnect.buttons.resendCodewalletSelector.converseAccount.titlenew_conversation.create_grouprecommendations.section_title
The review comment correctly points out that converse_match_maker doesn't follow this hierarchical pattern, while other navigation-related translations do (e.g., top_up.header_title).
Consider using hierarchical translation key pattern
The translation key converse_match_maker should follow the established hierarchical pattern used throughout the codebase. Consider changing it to converse_match_maker.header_title for better consistency with other navigation components.
🔗 Analysis chain
Consider using consistent translation key hierarchy.
While the implementation is correct, the translation key converse_match_maker doesn't follow the hierarchical pattern used in other files (e.g., top_up.header_title). Consider using a consistent pattern like converse_match_maker.header_title for better maintainability.
Let's verify the current translation key exists:
Also applies to: 15-15
Based on the extensive search results, I can see that translation keys are used throughout the codebase with various patterns. Let me search specifically for the hierarchical patterns to verify the review comment's claim.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the translation key definition in translation files
rg "converse_match_maker" --type yaml --type json
Length of output: 49
Script:
#!/bin/bash
# Let's first find all translation files
fd -e json -e yaml translations
# Then let's look for any translation keys in these files to understand the pattern
rg "header_title" --type yaml --type json -A 1 -B 1
Length of output: 85
Script:
#!/bin/bash
# Let's find all translation-related files in the project
fd -t f "i18n|translations|locales|lang"
# Let's also check the actual usage of translate function to understand patterns
rg "translate\(" -A 1 -B 1
Length of output: 75211
Script:
#!/bin/bash
# Search for translation keys with dot notation to understand the hierarchy patterns
rg "translate\([\"'].*\..*[\"']" -A 1 -B 1
# Also let's look at the actual usage in the file under review
rg "translate" screens/Navigation/ConverseMatchMakerNav.tsx
Length of output: 32282
| @@ -67,7 +68,7 @@ export default function Accounts( | |||
| items={[ | |||
| { | |||
| id: "add", | |||
| title: "Add an account", | |||
| title: translate("add_an_account"), | |||
There was a problem hiding this comment.
💡 Codebase verification
Translation key should follow the 'accounts' namespace pattern
The translation key "add_an_account" should be namespaced as "accounts.add_an_account" to maintain consistency with the codebase's translation patterns, where feature-specific translations use namespaced keys (e.g., "ephemeral_account_banner.title", "privyConnect.title", etc.).
🔗 Analysis chain
Consider namespace and memoization for translations
- The translation key
"add_an_account"lacks a namespace prefix, unlike other translations in the codebase. - Consider memoizing the translated items array to prevent unnecessary re-renders.
+ const addAccountItem = useMemo(() => ({
+ id: "add",
+ title: translate("accounts.add_an_account", "Add an Account"),
+ titleColor: primaryColor(colorScheme),
+ action: () => {
+ router.navigate("NewAccountNavigator");
+ },
+ }), [colorScheme]);
<TableView
- items={[
- {
- id: "add",
- title: translate("add_an_account"),
- titleColor: primaryColor(colorScheme),
- action: () => {
- router.navigate("NewAccountNavigator");
- },
- },
- ]}
+ items={[addAccountItem]}
style={{ margin: 0 }}
/>Based on the search results, I can see that translation keys in the codebase consistently follow a namespaced pattern using dots (e.g., "privyConnect.title.enterPhone", "walletSelector.title", "userProfile.buttons.continue", etc.). However, there are a few non-namespaced keys like "back", "cancel", etc., which are common/shared translations.
Let me verify if there are any other account-related translations to confirm the correct namespace pattern.
Based on the search results, I can see that account-related translations consistently use namespaces like "ephemeral_account_banner.title", while the key "add_an_account" in Accounts.tsx is an outlier. Let me verify if there are any other translations used in the Accounts screen to confirm the correct namespace pattern for this specific screen.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check translation key consistency
# Look for other direct translation keys without namespaces
rg "translate\([\"'][^\.]+[\"']\)" --type ts --type tsx
Length of output: 89
Script:
#!/bin/bash
# Search for translation patterns with and without namespaces
rg "translate\([\"'].*?[\"']\)" --type typescript --type-add 'typescript:*.{ts,tsx}'
# Also check translation usage in the specific file
cat screens/Accounts/Accounts.tsx
Length of output: 37833
Script:
#!/bin/bash
# Search for account-related translations
rg "translate\([\"'].*?account.*?[\"']\)" --type typescript --type-add 'typescript:*.{ts,tsx}'
Length of output: 1060
Script:
#!/bin/bash
# Search for translations in Accounts screen and related files
rg "translate\([\"'].*?[\"']\)" screens/Accounts/
Length of output: 133
| {translate("top_up.alternatively")} | ||
| <Text style={styles.bold}>{translate("top_up.usdc")}</Text>{" "} | ||
| {translate("top_up.native")} | ||
| <Text style={styles.bold}>{translate("top_up.base")}</Text> | ||
| {translate("top_up.to_your_address")} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using a single translation key with parameters
Concatenating translated segments can cause issues in languages with different word orders. Consider using a single translation key with parameters for better translation support.
- {translate("top_up.alternatively")}
- <Text style={styles.bold}>{translate("top_up.usdc")}</Text>{" "}
- {translate("top_up.native")}
- <Text style={styles.bold}>{translate("top_up.base")}</Text>
- {translate("top_up.to_your_address")}
+ {translate("top_up.instruction", {
+ usdc: (text) => <Text style={styles.bold}>{text}</Text>,
+ base: (text) => <Text style={styles.bold}>{text}</Text>
+ })}Translation key example:
{
"top_up": {
"instruction": "Alternatively, if you want to do it by yourself, send {usdc} native, not USDbC {base} to your address"
}
}| {translate("recommendations.no_recommendations")} | ||
| <Text style={styles.clickableText} onPress={openSignalList}> | ||
| find the current list here | ||
| {translate("recommendations.signal_list")} | ||
| </Text> | ||
| , please feel free to{" "} | ||
| {translate("recommendations.please_feel_free_to")} | ||
| <Text style={styles.clickableText} onPress={contactPol}> | ||
| contact our co-founder Pol | ||
| {translate("recommendations.contact_pol")} | ||
| </Text>{" "} | ||
| if you want us to add anything.{"\n\n"}Thank you! | ||
| {translate("recommendations.if_you_want_us_to_add_anything")} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using a single translation key for the complete message.
The current implementation uses multiple translate calls within a single text block, which might cause issues with sentence structure in different languages. Consider using a single translation key with placeholders.
- <Text style={styles.title}>
- {translate("recommendations.no_recommendations")}
- <Text style={styles.clickableText} onPress={openSignalList}>
- {translate("recommendations.signal_list")}
- </Text>
- {translate("recommendations.please_feel_free_to")}
- <Text style={styles.clickableText} onPress={contactPol}>
- {translate("recommendations.contact_pol")}
- </Text>{" "}
- {translate("recommendations.if_you_want_us_to_add_anything")}
- </Text>
+ <Text style={styles.title}>
+ {translate("recommendations.no_recommendations_full_message", {
+ signal_list: (
+ <Text style={styles.clickableText} onPress={openSignalList}>
+ {translate("recommendations.signal_list")}
+ </Text>
+ ),
+ contact_pol: (
+ <Text style={styles.clickableText} onPress={contactPol}>
+ {translate("recommendations.contact_pol")}
+ </Text>
+ )
+ })}
+ </Text>This approach allows translators to maintain proper sentence structure while preserving the clickable elements.
Committable suggestion skipped: line range outside the PR's diff.
Cleaned up most non-translated strings Added French
Cleaned up most non-translated strings
Added French
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Documentation
These updates significantly improve the user experience by ensuring that text is appropriately localized and error messages are more user-friendly.