How to handle / organize translatable fields
this blueprint refers to https:/
a translatable field may be translated optionally or mandatory.
new terms with mandatory translation get the status "translation check required" (see below) unless translated by the user himself.
for some languages (arabic, cyrilc, greek , ...) most fields will need a mandatory translation.
a translatable field can have 2 states when it's value changes (gets updated)
(1) untranslated - no further actions necessary - all languages "inherit" the new value
(2) translated - usually it will be necessary to update the translated terms too (unless it's a minor change or correction of typos)
suggestion: if translated fields exists the translation window pops up upon change and asks for update of the translated fields (show only translated fields?)
if the user can do it (authorization per language [and fields]) - the user does it - if not a request is sent to the translation team of the company. The terms needing a new translation change to state "translation check required".
fields with translated fields with this state are
* visually marked on screen (blinking or red flag?)
* internal documents in the translated language mark the term with a flag
* external documents may not use such terms (either use original or prohibit generation/
printed output needs an option to override the language used.
Example:
German company bills a french customer and sends the bill in french to the customer, but needs an additional German copy for its records.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Bug #319793: some more translatable fields | Invalid |
Bug #553133: Search with accents | Fix Released |