As GitLab grows internationally, and more users who don’t speak English will start using our product in their languages, we need to account for the UX of our international audiences.  GitLab is using many tools to help with **internationalization (i18n)**, such as libraries that handle i18n aspects like pluralization, dates, numbers, or currencies. However, what's less automated or not ever automated is the style, grammar, and spelling checks around **copywriting of UI text**, and specifically - adherence to **localizability requirements to message composition**. It is natural to inadvertently bake into code, or into message composition, our own internalized assumptions that are based on how the _English_ language works. The resulting gaps of that practice may only manifest when the translated UI text appears to a user on a page. At that point, if some translation looks “incorrect” to a customer user, the solution for us is not to re-translate the message, but to re-write the original English that caused the reported mis-translation. Such rewriting of messages can be very costly, because it will likely involve refactoring of the associated code. GitLab user interface text is stored in a [.pot file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/locale/gitlab.pot), and [is translated on the Crowdin translation management system by the wider community of volunteer translators and proofreaders](https://docs.gitlab.com/ee/development/i18n/). Original English messages are easy to translate when they follow translatability requirements. However, when messages are composed without translatability in mind, the result may be a seeming mistake in translation, often to no fault of a translator. When writing UI text, we need to account for different grammar structures in different languages, and should not make assumptions as to what those structures will be. It might be tempting to use common practices like concatenation of text message fragments, or interpolation (sometimes well justified, but needs to be done with localizability review). However, linguistically the resulting translated messages will not read as elegantly as English may.  It’s best to follow localizability practices, or better yet  - treat them as **localizability requirements to message composition**. We may also think of localizability as equals _accessibility_.  It does not matter what non-English languages we build or translate for, and whether we have customers who use the product in a certain language widely already (like Japanese), or we have very few users (like Ukrainian \[arbitrary example\]). The \*\*_un_\*\*translatability of English impacts all languages alike, and the UX of an international user as a persona in general. This epic will host relevant issues, MRs, experiments, and ideas around localizability / translatability of product user interface strings.