Feature proposal #5487
closed
Implement field specific language keys for field language strings
Description
Language strings used in fields should have a field specific key in addition to the generic key. This should be specific by field name. This will allow field by field translation as it's very likely to have multiple fields of the same type and need different strings for them.
Example case is the terms and conditions field. Evaluate each field individually to see if it needs this.
Updated by beat about 9 years ago
- Target version changed from CB 2.0.11 to CB 2.0.12
Updated by beat about 9 years ago
- Target version changed from CB 2.0.12 to CB 2.0.13
Updated by beat almost 9 years ago
- Target version changed from CB 2.0.13 to CB 2.0.14
Updated by beat over 8 years ago
- Target version changed from CB 2.0.14 to CB 2.0.15
Updated by beat about 8 years ago
- Target version changed from CB 2.0.15 to CB 2.1
Updated by krileon almost 8 years ago
This really only needs to apply to generic language strings that can not be overridden with a parameter.
Updated by krileon almost 8 years ago
The following strings have been added. At this time I don't see a need for any further specification on field language strings outside of terms and conditions.
FIELD_#_TERMS_FIELD_ACCEPT_URL_CONDITIONS
FIELD_#_TERMS_FIELD_I_AGREE_ON_THE_ABOVE_CONDITIONS
Replace # with field ID.
Updated by krileon almost 8 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
Implemented in MR !1193
If this is needed on a more mass scale then CBTxt should have a function to better accommodate this usage (e.g. generating a second key with a prefix automatically).