Request to change internal variable names in language files

Description
In the “Alias domain for website” form, the labels of the first two fields are generated using incorrect language keys.
This is not a functional issue, but a UI / language-key mapping bug that results in misleading field labels.

Issue 1 — First field (input field)
The first field (used to enter the alias name) does not use the expected language key host_txt.
Instead, it uses the language key of the second field (domain_txt).

Expected:

• First field → host_txt

Issue 2 — Second field (dropdown)

The second field (used to select the parent website) does not use the expected language key domain_txt.
Instead, it uses an incorrect key (parent_domain_id_txt).

Expected:

• Second field → domain_txt

Summary of required fixes

• Field 1: replace the current language key with host_txt
• Field 2: replace the current language key with domain_txt

Notes

• This issue creates confusion in the user interface.
• It prevents accurate translations.
• The “Subdomain for website” form already uses the correct language keys and can be used as a reference.
• No backend logic or database changes are required.

 

The report concerns only the assignment of language keys and their consistency across forms, independently of any terminological consideration.

 

I understand the constraint regarding internal variable names when the displayed label is considered correct.
After reviewing the forms again, I agree that the logic of the Alias domain panel is coherent as it currently stands.

The confusion mainly originates from the Subdomain panel, where the host_txt key, while technically defensible, remains semantically ambiguous: it refers here to a DNS subdomain label, not to a ‘host’ in the usual sense, which can be misleading.

In this context, it would indeed be more consistent for the field currently labelled via domain_txt to use a key, such as parent_domain_id_txt, in order to clearly reflect the notion of the parent website.

In the longer term, and without breaking existing logic, a more explicit key such as subdomain_txt could also help remove this ambiguity, while preserving the current internal structure.