WEB-239: Fix Tax Components view page translation and layout

[DeathGun44]

Description

Fixed untranslated account type labels on Tax Components view page.

Screenshots

Before: Untranslated labels

After: Properly translated

Checklist

• If you have multiple commits please combine them into one commit by squashing them
• Read and understood the contribution guidelines

Summary by CodeRabbit

• Refactor
  • Improved localization for account displays in the tax component view: account type labels now use dynamically constructed translation keys, while debit and credit account codes and names are shown in their original form (no longer passed through the translation system) for clearer, more consistent data presentation.

[coderabbitai]

Note

.coderabbit.yaml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)

Validation error: Unrecognized key(s) in object: 'pre_merge_checks'

⚙️ Configuration instructions

• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

This PR updates the tax component view template to build translation keys for account type labels at render time and stops translating debit account glCode and name, rendering them directly.

Changes

Cohort / File(s)	Summary
Template Translation & Rendering src/app/products/manage-tax-components/view-tax-component/view-tax-component.component.html	Replaced previous translation usage for debitAccountType and creditAccountType with dynamically constructed keys ('labels.inputs.accounting.' + value.split('.')[1].toUpperCase()) passed to the translate pipe. Removed translate/filtering for debitAccount.glCode and debitAccount.name, rendering raw values instead.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• WEB-593 Translate account types in the Transfer Details Page #3019: Similar template change composing translation keys from account-type values instead of displaying raw codes.

Suggested reviewers

• IOhacker
• alberto-art3ch

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main changes: fixing translation issues and layout for the Tax Components view page, which aligns with the code changes that replace direct text lookups with dynamic translation keys.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In
`@src/app/products/manage-tax-components/view-tax-component/view-tax-component.component.html`:
- Around line 42-45: The template expressions accessing
taxComponentData.debitAccountType.value.split('.')[1].toUpperCase() and the
identical creditAccountType variant can throw if value lacks a '.'; update both
expressions to safely handle missing separators by using optional chaining and a
fallback segment (e.g. use value?.split('.')?.[1] || 'UNKNOWN' before calling
toUpperCase()), and wrap the full concatenation in parentheses so the translate
pipe applies to the entire key string; locate these expressions in the
view-tax-component.component.html template and replace them accordingly for
strict-safe behavior.

🧹 Nitpick comments (1)

src/app/products/manage-tax-components/view-tax-component/view-tax-component.component.html (1)

34-47: Consider consolidating the duplicate @if blocks for account type label and value.

Each account type uses two separate @if blocks checking the same condition (e.g., lines 34 and 40 both check taxComponentData.debitAccountType). These could be combined into a single @if wrapping both the label and value divs, reducing duplication. This isn't introduced by this PR though, so feel free to defer.

Also applies to: 62-75

[DeathGun44]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[DeathGun44]

@IOhacker ready for re-review

[IOhacker]

Why this value is not translated?

[DeathGun44]

@IOhacker
Thanks for catching this! The account name shouldn't be translated because it's user-created database data, not a UI label.

The old code was concatenating 'labels.inputs.accounting.' + glCode, which created non-existent translation keys like 'labels.inputs.accounting.66'. The translation system only has keys for account types (LIABILITY, ASSET, INCOME), not for dynamic GL codes or account names.

I verified this is consistent with the rest of the codebase - similar components like
view-rule.component.html
and
manage-tax-components.component.html
display account names and GL codes without translation pipes.

Happy to discuss further if needed!