Fix: Language consistency in transaction history screen (MM-518)#3116
Open
Aryan-Baglane wants to merge 19 commits intoopenMF:developmentfrom
Open
Fix: Language consistency in transaction history screen (MM-518)#3116Aryan-Baglane wants to merge 19 commits intoopenMF:developmentfrom
Aryan-Baglane wants to merge 19 commits intoopenMF:developmentfrom
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds/updates many localization resource files across accounts and recent-transaction features and introduces labelRes-based mapping for transaction types, wiring localized labels from view models into screens for display. Changes
Sequence Diagram(s)sequenceDiagram
participant Repo as Repository
participant VM as ViewModel
participant Res as StringResources
participant UI as Screen
Note over Repo,VM: Fetch transactions list
Repo->>VM: provide Transactions[]
VM->>VM: Transactions.toUiTransaction() (map type -> labelRes)
VM->>Res: resolve labelRes via mapLoan/ShareTransactionTypeToRes / getLabelRes()
Res-->>VM: StringResource
VM-->>UI: UiTransaction(labelRes?, typeValue, amount, ...)
UI->>Res: stringResource(labelRes) if present
Res-->>UI: localized label text
UI->>UI: render transaction item with localized title (fallback to typeValue)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Member
Author
|
@CodeRabbit suggest some good pr title |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
Conventional Commit Style:
With Issue Reference: Concise: Descriptive: I'd recommend option 1 or option 4 (if you want to include the issue reference). They follow the conventional commit format with proper capitalization and clearly describe the fix without being too verbose. |
Aryan-Baglane
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (4)
feature/recent-transaction/src/commonMain/composeResources/values/strings.xml (1)
32-38: Consider aligning string key naming conventions between modules.The accounts module uses
feature_transaction_history_*prefixed keys (e.g.,feature_transaction_history_deposit), while the recent-transaction module uses unprefixed names (deposit,withdrawal, etc.). The accounts module also defines additional transaction type keys (disbursement,repayment,purchase,charge_payment,redeem) that are absent here.However, verification shows the recent-transaction code does not reference these additional transaction type keys, suggesting the current 6 keys are sufficient for this module's scope. If the two modules intentionally have different string key scopes and naming schemes, this is a valid modular design and no changes are needed.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/recent-transaction/src/commonMain/composeResources/values/strings.xml` around lines 32 - 38, The string keys in this file ("deposit", "withdrawal", "interest_posting", "fee_deduction", "transfer", "transaction") use an unprefixed naming convention that differs from the accounts module's `feature_transaction_history_*` prefixes and omits several transaction-type keys (e.g., `disbursement`, `repayment`, `purchase`, `charge_payment`, `redeem`); decide and apply one approach: either rename these six keys to the shared `feature_transaction_history_...` prefix to match the accounts module, or explicitly keep the current unprefixed scoped names (no change) and document that this module intentionally uses a local naming scope—if you choose the shared approach, update usages in code that reference "deposit"/"withdrawal"/etc. to the new `feature_transaction_history_*` names, and if you expect broader coverage add the missing transaction keys to mirror accounts.feature/recent-transaction/src/commonMain/kotlin/org/mifos/mobile/feature/recent/transaction/viewmodel/RecentTransactionViewModel.kt (1)
374-383:getLabelRes()always returns non-null, so thetypeValuefallback in the UI is dead code.Since every code path returns a
StringResource,labelReswill never benullfor recent transactions. The fallback?: transaction.typeValue.orEmpty()on line 257 ofRecentTransactionScreen.ktis unreachable. This means any unknown/future transaction type from the API will silently show the generic "Transaction" label instead of the raw API value.If that's intentional, consider changing the return type to non-nullable
StringResourceand removing the null-check in the UI. If the raw API value is preferred for unknown types, returnnullfrom theelsebranch.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/recent-transaction/src/commonMain/kotlin/org/mifos/mobile/feature/recent/transaction/viewmodel/RecentTransactionViewModel.kt` around lines 374 - 383, The getLabelRes() function currently always returns a non-null StringResource which makes the UI fallback transaction.typeValue.orEmpty() dead; decide which behavior you want and implement it: either change getLabelRes() signature to return a non-nullable StringResource and update callers (e.g., RecentTransactionScreen.kt) to remove the null-check/fallback, or change the else branch of TransactionType?.getLabelRes() to return null (and update the function signature to StringResource?) so unknown/future API types fall back to transaction.typeValue.orEmpty(); locate and update the getLabelRes() function and RecentTransactionScreen usage accordingly (function name: getLabelRes, UI usage: labelRes ?: transaction.typeValue.orEmpty()) to keep behavior consistent.feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt (2)
731-739: SavingsTransactions.toUiTransaction()does not populatelabelRes.Unlike the loan/recent-transaction paths, this conversion doesn't set
labelRes. The fallback inTransactionScreen.kt(line 205–206) callstransaction.type.getLabelRes()which covers savings types, so this works at runtime. However, for consistency across alltoUiTransaction()call sites, consider settinglabelReshere too.Proposed fix
fun Transactions.toUiTransaction() = UiTransaction( id = id?.toLong(), date = date, amount = amount, type = transactionType, typeValue = transactionType?.value, + labelRes = transactionType.getLabelRes(), isCredit = getTransactionCreditStatus(transactionType), currency = currency?.code ?: "USD", )🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt` around lines 731 - 739, The Transactions.toUiTransaction() mapper omits setting labelRes on UiTransaction; update this function (Transactions.toUiTransaction) to populate labelRes using the transactionType's label getter (e.g., transactionType?.getLabelRes() or transactionType.getLabelRes() as appropriate), ensuring you handle nullability and use the same helper used elsewhere so savings transactions have a consistent labelRes value when constructing UiTransaction.
802-814: Extract duplicatedgetLabelRes()logic into a shared utility function.The mapping logic in
TransactionViewModel.kt(lines 805–814) is duplicated inRecentTransactionViewModel.kt(lines 374–383). Both implementations use the sameTransactionTypefromcore.modeland apply identical mapping logic. While they reference different resource strings (e.g.,Res.string.feature_transaction_history_depositvsRes.string.deposit), the English string values are identical, indicating the resource namespace difference is purely a module convention.Consider extracting this extension into
core/commonor a dedicated utilities module to eliminate duplication and ensure consistent behavior across both features.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt` around lines 802 - 814, Duplicate mapping logic for TransactionType?.getLabelRes found in TransactionViewModel.kt and RecentTransactionViewModel.kt; extract this extension into a shared location (e.g., core/common) as a single extension function TransactionType?.getLabelRes() and have both TransactionViewModel and RecentTransactionViewModel import and call that shared function; when extracting, unify the resource references by either using a common Res namespace from core (or accept a resource provider parameter if modules require different Res objects) so both callers use the same centralized mapping implementation and remove the duplicated code.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@feature/accounts/src/commonMain/composeResources/values-es/strings.xml`:
- Around line 97-106: Add the missing Spanish translation for the key
feature_transaction_history_redeem to this locale file so it doesn't fall back
to English; insert a new string entry with
name="feature_transaction_history_redeem" and an appropriate Spanish value
(e.g., "Canje" or "Redención") alongside the other transaction keys (same block
where feature_transaction_history_deposit,
feature_transaction_history_withdrawal, etc. are defined).
In `@feature/accounts/src/commonMain/composeResources/values-fa/stirngs.xml`:
- Around line 1-102: The file is misnamed "stirngs.xml" so the Compose
Multiplatform resources are ignored; rename the resource file from "stirngs.xml"
to "strings.xml" (preserving the XML content and <resources> block and string
names like feature_account_title, feature_transaction_detail_receipt, etc.) so
the Persian translations are picked up by the resource system.
In `@feature/accounts/src/commonMain/composeResources/values-pl/strings.xml`:
- Line 56: Rename the Polish string resource key
feature_transaction_filter_debet to feature_transaction_filter_debit so it
matches other locales; update the <string
name="feature_transaction_filter_debet"> entry to use
name="feature_transaction_filter_debit" (keeping the value "Obciążenie (Debit)")
to ensure lookups resolve consistently across locales and no fallback occurs.
In `@feature/accounts/src/commonMain/composeResources/values-sw/strings.xml`:
- Line 62: The Swahili translation for the string resource
feature_transaction_filter_past_2_years is incorrect—replace "Miezi 2 Iliopita"
with the correct wording using "Miaka" for years (e.g., "Miaka 2 Iliopita") so
the key feature_transaction_filter_past_2_years accurately reads "Past 2 Years";
update the value string for that resource accordingly.
In `@feature/accounts/src/commonMain/composeResources/values-te/strings.xml`:
- Line 67: The string key uses a double underscore
(feature_no__filtered_transactions_found); rename it to
feature_no_filtered_transactions_found across all 16 locale strings.xml files
and update all references in Kotlin (e.g., TransactionViewModel.kt and
TransactionScreen.kt) to the new key; perform a repo-wide search-and-replace for
feature_no__filtered_transactions_found →
feature_no_filtered_transactions_found, rebuild to ensure no missing resource
references, and run tests/compile to confirm the updated resource key is
resolved.
In
`@feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt`:
- Around line 760-769: The mapping in mapLoanTransactionTypeToRes wrongly maps
"recovery repayment" (and waivers) to unrelated keys; update this function to
use dedicated string resources for these types (e.g., replace
Res.string.feature_loan_account_filter_active with a new
Res.string.feature_transaction_history_recovery_repayment, and replace
feature_transaction_detail_interest and feature_transaction_detail_fees with
feature_transaction_history_interest_waiver and
feature_transaction_history_fee_waiver respectively), and add those new keys to
your strings resource files with proper translations; if you cannot add
translations yet, at minimum map "recovery repayment" to a clearly named
transaction string (not feature_loan_account_filter_active) so the UI no longer
shows "Active".
In
`@feature/recent-transaction/src/commonMain/composeResources/values-fa/strings.xml`:
- Line 13: The Persian string resource named "no_transaction" contains a typo
("تراکنی") and should be corrected to "تراکنشی وجود ندارد"; update the value of
the string resource with name "no_transaction" in values-fa strings.xml to read
"تراکنشی وجود ندارد" so it matches other uses of "تراکنش" and fixes the missing
"ش".
---
Duplicate comments:
In `@feature/accounts/src/commonMain/composeResources/values-km/strings.xml`:
- Line 67: The resource key feature_no__filtered_transactions_found contains a
duplicated double underscore; rename the string resource key to
feature_no_filtered_transactions_found (single underscore) in the strings.xml
entry and update all references/usages in code and tests to the new key so
lookups resolve correctly, preserving the translated value text exactly; ensure
any generated resource maps or enums that reference
feature_no__filtered_transactions_found are regenerated or updated to the new
identifier.
In `@feature/accounts/src/commonMain/composeResources/values-my/strings.xml`:
- Line 67: The resource key feature_no__filtered_transactions_found contains an
accidental double underscore; rename it to
feature_no_filtered_transactions_found (single underscore) in strings.xml and
update all usages/references in the codebase (e.g., any calls that reference
feature_no__filtered_transactions_found such as getString/R.string/translation
lookup sites) to the new key to avoid the duplicate-key issue flagged earlier.
In `@feature/accounts/src/commonMain/composeResources/values-ur/strings.xml`:
- Line 67: The resource key feature_no__filtered_transactions_found contains an
accidental double underscore; update the key to match the canonical name used
elsewhere (e.g., feature_no_filtered_transactions_found) in this file and ensure
all usages reference the corrected key (search for
feature_no__filtered_transactions_found and replace with
feature_no_filtered_transactions_found in strings.xml and any code or other
locale files like the Telugu strings so keys remain consistent).
---
Nitpick comments:
In
`@feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt`:
- Around line 731-739: The Transactions.toUiTransaction() mapper omits setting
labelRes on UiTransaction; update this function (Transactions.toUiTransaction)
to populate labelRes using the transactionType's label getter (e.g.,
transactionType?.getLabelRes() or transactionType.getLabelRes() as appropriate),
ensuring you handle nullability and use the same helper used elsewhere so
savings transactions have a consistent labelRes value when constructing
UiTransaction.
- Around line 802-814: Duplicate mapping logic for TransactionType?.getLabelRes
found in TransactionViewModel.kt and RecentTransactionViewModel.kt; extract this
extension into a shared location (e.g., core/common) as a single extension
function TransactionType?.getLabelRes() and have both TransactionViewModel and
RecentTransactionViewModel import and call that shared function; when
extracting, unify the resource references by either using a common Res namespace
from core (or accept a resource provider parameter if modules require different
Res objects) so both callers use the same centralized mapping implementation and
remove the duplicated code.
In
`@feature/recent-transaction/src/commonMain/composeResources/values/strings.xml`:
- Around line 32-38: The string keys in this file ("deposit", "withdrawal",
"interest_posting", "fee_deduction", "transfer", "transaction") use an
unprefixed naming convention that differs from the accounts module's
`feature_transaction_history_*` prefixes and omits several transaction-type keys
(e.g., `disbursement`, `repayment`, `purchase`, `charge_payment`, `redeem`);
decide and apply one approach: either rename these six keys to the shared
`feature_transaction_history_...` prefix to match the accounts module, or
explicitly keep the current unprefixed scoped names (no change) and document
that this module intentionally uses a local naming scope—if you choose the
shared approach, update usages in code that reference
"deposit"/"withdrawal"/etc. to the new `feature_transaction_history_*` names,
and if you expect broader coverage add the missing transaction keys to mirror
accounts.
In
`@feature/recent-transaction/src/commonMain/kotlin/org/mifos/mobile/feature/recent/transaction/viewmodel/RecentTransactionViewModel.kt`:
- Around line 374-383: The getLabelRes() function currently always returns a
non-null StringResource which makes the UI fallback
transaction.typeValue.orEmpty() dead; decide which behavior you want and
implement it: either change getLabelRes() signature to return a non-nullable
StringResource and update callers (e.g., RecentTransactionScreen.kt) to remove
the null-check/fallback, or change the else branch of
TransactionType?.getLabelRes() to return null (and update the function signature
to StringResource?) so unknown/future API types fall back to
transaction.typeValue.orEmpty(); locate and update the getLabelRes() function
and RecentTransactionScreen usage accordingly (function name: getLabelRes, UI
usage: labelRes ?: transaction.typeValue.orEmpty()) to keep behavior consistent.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt (1)
731-739:⚠️ Potential issue | 🟠 Major
Transactions.toUiTransaction()never setslabelRes— savings transactions will show no localized label.
getLabelRes()(lines 802–814) is the purpose-built extension that mapsTransactionTypeboolean flags to the localizedfeature_transaction_history_*resources, but it is never called. As a result, savings account transactions always getlabelRes = null, while loan transactions (viamapLoanTransactionTypeToRes) and share transactions (viamapShareTransactionTypeToRes) are fully localized. This directly contradicts the PR's goal of language consistency across the transaction history screen.
getLabelRes()is also declaredinternal, so it cannot be reached fromfeature/recent-transactionmodule — making it dead code in the current state.🐛 Proposed fix
fun Transactions.toUiTransaction() = UiTransaction( id = id?.toLong(), date = date, amount = amount, type = transactionType, typeValue = transactionType?.value, + labelRes = transactionType.getLabelRes(), isCredit = getTransactionCreditStatus(transactionType), currency = currency?.code ?: "USD", )Also applies to: 802-814
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt` around lines 731 - 739, Transactions.toUiTransaction() never sets UiTransaction.labelRes, so savings transactions lack localized labels; update Transactions.toUiTransaction() to set labelRes = getLabelRes(transactionType) (or call the mapping helper you have) and ensure getLabelRes() is accessible from the module where Transactions is used (make it public/internal-to-public or move the mapping into a shared place) so the mapping logic is actually invoked; keep existing loan/share mappings (mapLoanTransactionTypeToRes, mapShareTransactionTypeToRes) untouched and ensure null-safe handling when transactionType or its flags are absent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@feature/accounts/src/commonMain/composeResources/values-ar/strings.xml`:
- Around line 102-104: The three entries
feature_transaction_history_recovery_repayment,
feature_transaction_history_interest_waiver, and
feature_transaction_history_fee_waiver currently contain Urdu text and must be
replaced with proper Arabic translations in values-ar/strings.xml; open those
string resources and substitute the Urdu phrases with correct Arabic equivalents
(using Arabic characters such as Arabic kāf U+0643 and Arabic vocabulary for
"repayment recovery", "interest waiver", and "fee waiver"), then save and verify
the Android resource builds and displays correctly in Arabic locale.
In `@feature/accounts/src/commonMain/composeResources/values-fa/strings.xml`:
- Around line 91-102: Add the three missing Persian translation keys referenced
by mapLoanTransactionTypeToRes in TransactionViewModel.kt: define
feature_transaction_history_recovery_repayment,
feature_transaction_history_interest_waiver, and
feature_transaction_history_fee_waiver in the strings.xml (values-fa) resource
block before the closing </resources>; use appropriate Persian translations for
"recovery repayment", "interest waiver", and "fee waiver" so Persian users don't
fall back to English when those loan transaction types are displayed.
---
Outside diff comments:
In
`@feature/accounts/src/commonMain/kotlin/org/mifos/mobile/feature/accounts/accountTransactions/TransactionViewModel.kt`:
- Around line 731-739: Transactions.toUiTransaction() never sets
UiTransaction.labelRes, so savings transactions lack localized labels; update
Transactions.toUiTransaction() to set labelRes = getLabelRes(transactionType)
(or call the mapping helper you have) and ensure getLabelRes() is accessible
from the module where Transactions is used (make it public/internal-to-public or
move the mapping into a shared place) so the mapping logic is actually invoked;
keep existing loan/share mappings (mapLoanTransactionTypeToRes,
mapShareTransactionTypeToRes) untouched and ensure null-safe handling when
transactionType or its flags are absent.
---
Duplicate comments:
In `@feature/accounts/src/commonMain/composeResources/values-sw/strings.xml`:
- Line 62: The string resource feature_transaction_filter_past_2_years contains
a wrong word ("Miezi" meaning months); update its translation to use "Miaka"
(years) so the value reads "Miaka 2 Iliopita" for the string with name
feature_transaction_filter_past_2_years in values-sw/strings.xml.
In `@feature/accounts/src/commonMain/composeResources/values-te/strings.xml`:
- Line 67: The resource key feature_no__filtered_transactions_found contains an
accidental double underscore; rename it to
feature_no_filtered_transactions_found and update all references/usages to that
string resource (e.g., code that accesses
R.string.feature_no__filtered_transactions_found or
getString("feature_no__filtered_transactions_found")) so they point to the new
key, and mirror the same rename across other locale string files to keep
resource IDs consistent.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@feature/accounts/src/commonMain/composeResources/values-ar/strings.xml`:
- Around line 55-56: Replace the mixed-language Arabic strings by fully
localized Arabic terms: update the resources feature_transaction_filter_credit
and feature_transaction_filter_debit to use Arabic equivalents (e.g., "إيداع
(ائتمان)" or simply "إيداع — ائتمان"/"سحب (خصم)" or "سحب — خصم") or prefer
standard single-word labels ("إيداع — ائتمان" / "سحب — خصم" or "دائن" / "مدين")
so the values-ar strings for feature_transaction_filter_credit and
feature_transaction_filter_debit contain only Arabic text and consistent
financial terminology.
Contributor
|
@Aryan-Baglane It looks like both the screens have been handled in a recent PR that was merged #3115 |
Contributor
|
@Aryan-Baglane I think you should close this with a comment referencing the merged PR. |
Member
Author
ok can i close this pr now |
Member
Author
|
this pr is done already with the pr #3115 |
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
feature/accounts/src/commonMain/composeResources/values-ar/strings.xml (1)
21-21: Optional: align "pending approval" phrasing across loan and savings filters.Line 21 (
feature_loan_account_filter_approval_pending) uses "قيد الموافقة" while line 39 (feature_savings_filter_pending_account) uses "في انتظار الموافقة" for the same conceptual state. Both are correct Arabic, but consistent phrasing improves UX coherence across account types.🌐 Suggested alignment (pick one form)
- <string name="feature_loan_account_filter_approval_pending">قيد الموافقة</string> + <string name="feature_loan_account_filter_approval_pending">في انتظار الموافقة</string>or, conversely, align line 39 to line 21's more concise form:
- <string name="feature_savings_filter_pending_account">في انتظار الموافقة</string> + <string name="feature_savings_filter_pending_account">قيد الموافقة</string>Also applies to: 39-39
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/composeResources/values-ar/strings.xml` at line 21, Two similar strings use inconsistent Arabic phrasing for the same state: feature_loan_account_filter_approval_pending ("قيد الموافقة") and feature_savings_filter_pending_account ("في انتظار الموافقة"); pick one phrasing and make both keys use it for consistency (e.g., change feature_savings_filter_pending_account to "قيد الموافقة" or change feature_loan_account_filter_approval_pending to "في انتظار الموافقة") so the UX reads coherently across loan and savings filters.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@feature/accounts/src/commonMain/composeResources/values-ar/strings.xml`:
- Around line 55-56: The strings feature_transaction_filter_credit and
feature_transaction_filter_debit have been fully localized to Arabic ("إيداع"
and "خصم") and no further changes are required; leave these resource entries
as-is (no edits to feature_transaction_filter_credit or
feature_transaction_filter_debit) and proceed with approving/merging the change.
---
Nitpick comments:
In `@feature/accounts/src/commonMain/composeResources/values-ar/strings.xml`:
- Line 21: Two similar strings use inconsistent Arabic phrasing for the same
state: feature_loan_account_filter_approval_pending ("قيد الموافقة") and
feature_savings_filter_pending_account ("في انتظار الموافقة"); pick one phrasing
and make both keys use it for consistency (e.g., change
feature_savings_filter_pending_account to "قيد الموافقة" or change
feature_loan_account_filter_approval_pending to "في انتظار الموافقة") so the UX
reads coherently across loan and savings filters.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
feature/accounts/src/commonMain/composeResources/values-mr/strings.xml (1)
78-91: Inconsistent parenthetical-English annotation style within transaction history entries.Several entries earlier in the file include an English clarification in parentheses (e.g., line 78
ठेव (Deposit), line 79काढून घेणे (Withdrawal)) while the remaining entries on lines 80–91 do not (e.g.,व्याज जमा,कर्ज वितरण,कर्ज परतफेड). Given that this PR's stated goal is language consistency, apply the parenthetical pattern uniformly — either add English hints to all entries or remove them from all.♻️ Example: uniform parenthetical annotations for the un-annotated entries
- <string name="feature_transaction_history_interest_posting">व्याज जमा</string> - <string name="feature_transaction_history_fee_deduction">शुल्क कपात</string> - <string name="feature_transaction_history_transfer">हस्तांतरण</string> - <string name="feature_transaction_history_transaction">व्यवहार</string> - <string name="feature_transaction_history_disbursement">कर्ज वितरण</string> - <string name="feature_transaction_history_repayment">कर्ज परतफेड</string> - <string name="feature_transaction_history_purchase">खरेदी</string> - <string name="feature_transaction_history_charge_payment">शुल्क पेमेंट</string> - <string name="feature_transaction_history_redeem">रिडीम</string> - <string name="feature_transaction_history_recovery_repayment">वसुली परतफेड</string> - <string name="feature_transaction_history_interest_waiver">व्याज माफी</string> - <string name="feature_transaction_history_fee_waiver">शुल्क माफी</string> + <string name="feature_transaction_history_interest_posting">व्याज जमा (Interest Posting)</string> + <string name="feature_transaction_history_fee_deduction">शुल्क कपात (Fee Deduction)</string> + <string name="feature_transaction_history_transfer">हस्तांतरण (Transfer)</string> + <string name="feature_transaction_history_transaction">व्यवहार (Transaction)</string> + <string name="feature_transaction_history_disbursement">कर्ज वितरण (Disbursement)</string> + <string name="feature_transaction_history_repayment">कर्ज परतफेड (Repayment)</string> + <string name="feature_transaction_history_purchase">खरेदी (Purchase)</string> + <string name="feature_transaction_history_charge_payment">शुल्क पेमेंट (Charge Payment)</string> + <string name="feature_transaction_history_redeem">रिडीम (Redeem)</string> + <string name="feature_transaction_history_recovery_repayment">वसुली परतफेड (Recovery Repayment)</string> + <string name="feature_transaction_history_interest_waiver">व्याज माफी (Interest Waiver)</string> + <string name="feature_transaction_history_fee_waiver">शुल्क माफी (Fee Waiver)</string>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/composeResources/values-mr/strings.xml` around lines 78 - 91, The file mixes Marathi entries with and without English parenthetical clarifications; make the style consistent by adding English hints in parentheses to the un-annotated keys so they match the existing pattern (e.g., "ठेव (Deposit)"); update the following string resources to append the English term in parentheses: feature_transaction_history_interest_posting -> "व्याज जमा (Interest Posting)", feature_transaction_history_fee_deduction -> "शुल्क कपात (Fee Deduction)", feature_transaction_history_transfer -> "हस्तांतरण (Transfer)", feature_transaction_history_transaction -> "व्यवहार (Transaction)", feature_transaction_history_disbursement -> "कर्ज वितरण (Disbursement)", feature_transaction_history_repayment -> "कर्ज परतफेड (Repayment)", feature_transaction_history_purchase -> "खरेदी (Purchase)", feature_transaction_history_charge_payment -> "शुल्क पेमेंट (Charge Payment)", feature_transaction_history_redeem -> "रिडीम (Redeem)", feature_transaction_history_recovery_repayment -> "वसुली परतफेड (Recovery Repayment)", feature_transaction_history_interest_waiver -> "व्याज माफी (Interest Waiver)", feature_transaction_history_fee_waiver -> "शुल्क माफी (Fee Waiver)".feature/accounts/src/commonMain/composeResources/values-de/strings.xml (1)
79-84: Consider a more idiomatic German term forfeature_transaction_history_disbursement.Both
feature_transaction_history_withdrawal(line 79) andfeature_transaction_history_disbursement(line 84) resolve to the root wordAuszahlung, differentiated only by a parenthetical qualifier. German compound nouns are a more idiomatic way to distinguish these concepts.✏️ Suggested alternative
- <string name="feature_transaction_history_disbursement">Auszahlung (Kredit)</string> + <string name="feature_transaction_history_disbursement">Kreditauszahlung</string>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/composeResources/values-de/strings.xml` around lines 79 - 84, The German translation for feature_transaction_history_disbursement should be made more idiomatic by using a compound noun instead of a parenthetical qualifier; update the value for the string name feature_transaction_history_disbursement to a compound like "Kreditauszahlung" (leaving feature_transaction_history_withdrawal as "Auszahlung") so the two entries are clearly and idiomatically distinct.feature/accounts/src/commonMain/composeResources/values-hi/strings.xml (2)
105-107: Remove excess trailing blank lines.Three consecutive blank lines before
</resources>are inconsistent with the single-blank-line separation used elsewhere in the file.🧹 Proposed fix
<string name="feature_transaction_history_fee_waiver">शुल्क माफी</string> - - - </resources>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/composeResources/values-hi/strings.xml` around lines 105 - 107, Remove the extra trailing blank lines before the closing resources tag in strings.xml: collapse the three consecutive blank lines down to a single blank line (or none if project style prefers) immediately before the </resources> tag so the file matches the single-blank-line separation used elsewhere.
91-104: Remove trailing blank lines before</resources>and consider a more idiomatic Hindi term for "redeem".The file has three consecutive blank lines at lines 105-107 before the closing
</resources>tag. Clean this up to maintain consistency with file formatting standards.For
feature_transaction_history_redeem, "रिडीम" (transliteration) is widely accepted in Indian fintech UIs, but the more idiomatic Hindi term "भुनाना" (or "मोचन") could be considered as an alternative.The 14 transaction history strings are new additions and do not duplicate content already present in the development branch.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@feature/accounts/src/commonMain/composeResources/values-hi/strings.xml` around lines 91 - 104, Remove the extra blank lines before the closing </resources> tag (there are three blank lines after the last entry) to match file formatting, and for the string feature_transaction_history_redeem replace the transliterated "रिडीम" with a more idiomatic Hindi term such as "भुनाना" (or "मोचन") by updating the value of the feature_transaction_history_redeem string; leave the other new strings (feature_transaction_history_deposit, feature_transaction_history_withdrawal, ..., feature_transaction_history_fee_waiver) unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@feature/accounts/src/commonMain/composeResources/values-gu/strings.xml`:
- Line 68: The string resource feature_transaction_detail_status_reversed
currently mixes English inside Gujarati ("રદ થયેલ (Reversed)"); update the value
for feature_transaction_detail_status_reversed to a fully Gujarati term (e.g.,
"રિવર્સ્ડ" or "ઉલટાવેલ") or, if you intend to keep the English domain term,
document that decision and apply the exact same label across all locale files so
translations remain consistent; change the value in values-gu/strings.xml
accordingly and ensure other locale resource files reflect the chosen
convention.
In `@feature/accounts/src/commonMain/composeResources/values-hu/strings.xml`:
- Around line 49-53: The strings for transaction time-range filters are
inconsistent: feature_transaction_filter_past_month uses "Múlt hónap" while the
others use "Elmúlt …"; update feature_transaction_filter_past_month to use the
same "Elmúlt hónap" phrasing so all entries
(feature_transaction_filter_past_month,
feature_transaction_filter_past_3_months,
feature_transaction_filter_past_6_months,
feature_transaction_filter_past_1_year, feature_transaction_filter_past_2_years)
follow the "Elmúlt …" pattern.
In `@feature/accounts/src/commonMain/composeResources/values-ms/strings.xml`:
- Around line 38-39: The file contains inconsistent Malay terms for the same
concept: change the value of the `feature_transaction_filter` string to use the
same term as `feature_savings_filter` and
`feature_transaction_filter_icon_description` (i.e., replace "Tapis" with
"Penapis") so all three keys `feature_savings_filter`,
`feature_transaction_filter`, and `feature_transaction_filter_icon_description`
use "Penapis" consistently; update the `feature_transaction_filter` string value
accordingly and run a quick pass to ensure no other duplicate keys still use
"Tapis".
- Line 69: The string resource feature_transaction_detail_receipt currently
reads "No Resit #", which redundantly uses both "No" and "#" for number; update
the value to use a single convention (for example "Resit No." or "No Resit" or
"Resit #") and ensure spelling remains "Resit" if Malay is intended; modify the
<string name="feature_transaction_detail_receipt"> value accordingly so only one
numbering convention is used.
---
Duplicate comments:
In `@feature/accounts/src/commonMain/composeResources/values-ar/strings.xml`:
- Around line 89-91: The Arabic translations for the transaction history strings
have been corrected; verify and commit the updated resource entries by ensuring
the string resource keys feature_transaction_history_recovery_repayment,
feature_transaction_history_interest_waiver, and
feature_transaction_history_fee_waiver contain the provided Arabic texts (سداد
استرداد, إعفاء من الفائدة, إعفاء من الرسوم) and remove any leftover Urdu text or
duplicate entries so the strings.xml for the Arabic locale only includes these
correct translations.
- Around line 47-48: The Arabic translations for credit/debit are correctly
localized as string resources feature_transaction_filter_credit="دائن" and
feature_transaction_filter_debit="مدين"; ensure these exact resource keys exist
only once in values-ar/strings.xml (remove any duplicated entries), save the
file with UTF-8 encoding, and leave the English token references removed so the
locale is fully localized.
In `@feature/accounts/src/commonMain/composeResources/values-es/strings.xml`:
- Around line 78-91: All 14 transaction history string keys are present now
including feature_transaction_history_redeem ("Canjear"); please mark the change
as approved/merge the PR and ensure the strings.xml entry for
feature_transaction_history_redeem remains included alongside the other
feature_transaction_history_* keys to prevent regressions.
In `@feature/accounts/src/commonMain/composeResources/values-te/strings.xml`:
- Line 57: The string resource key contains a stray double underscore
("feature_no__filtered_transactions_found") — rename it to
"feature_no_filtered_transactions_found" consistently across all 16 locale
strings.xml files and update every reference in Kotlin code (e.g.,
TransactionViewModel.kt and TransactionScreen.kt) to use the new key; search the
repo for the old key, replace occurrences, run a resources rebuild (or gradle
sync) and verify no missing-resource compile errors remain.
---
Nitpick comments:
In `@feature/accounts/src/commonMain/composeResources/values-de/strings.xml`:
- Around line 79-84: The German translation for
feature_transaction_history_disbursement should be made more idiomatic by using
a compound noun instead of a parenthetical qualifier; update the value for the
string name feature_transaction_history_disbursement to a compound like
"Kreditauszahlung" (leaving feature_transaction_history_withdrawal as
"Auszahlung") so the two entries are clearly and idiomatically distinct.
In `@feature/accounts/src/commonMain/composeResources/values-hi/strings.xml`:
- Around line 105-107: Remove the extra trailing blank lines before the closing
resources tag in strings.xml: collapse the three consecutive blank lines down to
a single blank line (or none if project style prefers) immediately before the
</resources> tag so the file matches the single-blank-line separation used
elsewhere.
- Around line 91-104: Remove the extra blank lines before the closing
</resources> tag (there are three blank lines after the last entry) to match
file formatting, and for the string feature_transaction_history_redeem replace
the transliterated "रिडीम" with a more idiomatic Hindi term such as "भुनाना" (or
"मोचन") by updating the value of the feature_transaction_history_redeem string;
leave the other new strings (feature_transaction_history_deposit,
feature_transaction_history_withdrawal, ...,
feature_transaction_history_fee_waiver) unchanged.
In `@feature/accounts/src/commonMain/composeResources/values-mr/strings.xml`:
- Around line 78-91: The file mixes Marathi entries with and without English
parenthetical clarifications; make the style consistent by adding English hints
in parentheses to the un-annotated keys so they match the existing pattern
(e.g., "ठेव (Deposit)"); update the following string resources to append the
English term in parentheses: feature_transaction_history_interest_posting ->
"व्याज जमा (Interest Posting)", feature_transaction_history_fee_deduction ->
"शुल्क कपात (Fee Deduction)", feature_transaction_history_transfer -> "हस्तांतरण
(Transfer)", feature_transaction_history_transaction -> "व्यवहार (Transaction)",
feature_transaction_history_disbursement -> "कर्ज वितरण (Disbursement)",
feature_transaction_history_repayment -> "कर्ज परतफेड (Repayment)",
feature_transaction_history_purchase -> "खरेदी (Purchase)",
feature_transaction_history_charge_payment -> "शुल्क पेमेंट (Charge Payment)",
feature_transaction_history_redeem -> "रिडीम (Redeem)",
feature_transaction_history_recovery_repayment -> "वसुली परतफेड (Recovery
Repayment)", feature_transaction_history_interest_waiver -> "व्याज माफी
(Interest Waiver)", feature_transaction_history_fee_waiver -> "शुल्क माफी (Fee
Waiver)".
revanthkumarJ
approved these changes
Feb 22, 2026
Contributor
|
@Aryan-Baglane stash your commits into 1 before the final merge . Rest its fine |
Contributor
|
@piyushs-05 as rajan sir do squash and merge anyway there is no need to separately squash all commits into a single one |
amanna13
reviewed
Feb 23, 2026
Member
amanna13
left a comment
amanna13
left a comment
There was a problem hiding this comment.
Hey @Aryan-Baglane! As far as I can recall this has already been implemented with ref to - #3115.
Can you let us know why this has been reopened ?
Member
Author
|
@amanna13 hey i know that but this pr also resolve the the translation for the history screen which are accessed through saving account loan account and shared account on home screen |
biplab1
requested changes
Feb 23, 2026
Contributor
biplab1
left a comment
biplab1
left a comment
There was a problem hiding this comment.
It looks like the merge conflicts have not been properly resolved. Please review.
Member
Author
|
@biplab1 sir i have revert all the changes occured due to conflict |
Member
|
@Aryan-Baglane Update the branch |
Collaborator
|
@Aryan-Baglane Please refrain from submitting changes for multiple features in a single pull request; feel free to submit them as separate pull requests. @amanna13 @biplab1 Has this problem been resolved in a different pull request? |
Member
Author
|
@niyajali sir there are 4 transaction screen first on home screen and other are in saving account loan and shared account so i just added the string for those screen thats why i have commit changes for two fetures folder and the previous pr which was made by aditya he just added the strings for the transaction details screen and i have added the strings for transaction history these two screens are different thats why some commits got conflicts so i have resolved those conflicts so my pr is little bit different than aditya's pr |
Contributor
|
@niyajali There was some confusion with the screens addressed in another PR, however, we found that there was a difference in the screens handled in each of these PRs. I will review it soon. |
Contributor
|
@Aryan-Baglane Please review the Files changed section in the PR, you’ll see that several changes are being overwritten. |
biplab1
reviewed
Mar 5, 2026
biplab1
reviewed
Mar 5, 2026
biplab1
reviewed
Apr 3, 2026
biplab1
requested changes
Apr 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes - MM-518
Fix - Fix the issue of the language inconsistency in transaction history screen
Please Add Screenshots If there are any UI changes.
Screen.Recording.2026-02-18.at.12.35.39.AM.mov
Please make sure these boxes are checked before submitting your pull request - thanks!
Run the static analysis check
./gradlew checkorci-prepush.shto make sure you didn't break anythingIf you have multiple commits please combine them into one commit by squashing them.
Summary by CodeRabbit
New Features
Localization