Add documentation about not exporting translations strings
What does this MR do and why?
We change the currently recommended approach to export constants for translations and instead focus on having them within the Vue component itself and avoid importing copy in specs. This has been raised several times. Two recent examples (internal links):
- https://gitlab.slack.com/archives/C9Q5V0597/p1686055242228529
- https://gitlab.slack.com/archives/C0GQHHPGW/p1690397155000329
On top of this, we have an issue with some support: #390934 (closed)
In both threads and the RFC, the takeaways were that there is at least a risk factor high enough to warrant against using exporting constants for i18n, and even more so when it comes to importing them for tests. There has been no strong arguments for this pattern. The only benefit that has been listed is to allow tests to still pass if we update the copy, but it is not a strong one. Update a spec with copy updates should take a minute or two at most and is not that common.
Risks of false positive aside, tests should be as simple as possible and importing constants or passing through the wrapper.vm to get the i18n
object makes them harder to reason about.
Screenshots or screen recordings
Before | After |
---|---|
|
|
How to set up and validate locally
Green pipeline is all we need here.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.