Skip to content

Add documentation about not exporting translations strings

Frédéric Caplette requested to merge fc-add-docs-about-copy-strings-constants into master

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):

  1. https://gitlab.slack.com/archives/C9Q5V0597/p1686055242228529
  2. 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 
// constants.js
import { __ } from '~/locale';
export const PAGE_TITLE = __('Some awesome title!');

// some_spec.js
import { PAGE_TITLE } from 'constants.js';

expect(wrapper.text()).toBe(PAGE_TITLE);
 
// constants.js



// some_spec.js
import { __ } from '~/locale';

expect(wrapper.text()).toBe(__('Some awesome title!'));

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.

Edited by Kos Palchyk

Merge request reports