Follow-up to #2363099: Using translated field definition descriptions in entity schema results in different schema definitions, resulting in update.php changes.

Problem/Motivation

The use of translatable labels and descriptions in base field definitions causes several problems:

1. We have some serious issues with calling t() that early due to recursion when the global user object is a content entity: #2345611: [pp-1] Load user entity in Cookie AuthenticationProvider instead of using manual queries
2. It makes unit testing hard because of the t() calls there.
3. We have tons of t() calls due to field definition labels and descriptions, often in early bootstrap and possibly for anonymous/normal users, polluting their translation cache with stuff they will never need.

Proposed resolution

Drop t() in base field definitions and instead translate when getLabel()/getTranslation() is called.
Adding getUntranslatedLabel()/Description() methods that we can use in places where do *not* want a translated version. Something that is impossible now.

We could also always use a translation wrapper and add a method to get the untranslated text out on that, but manually using the translation wrapper in those places may be annoying and people will forget to do that. See the issue referenced above.

Remaining tasks

Discuss. Implement. Review. Commit.

User interface changes

None.

API changes

Expectations about base field definition labels and descriptions will be different. They will be expected in English rather than translated.

Comments

almaudoh’s picture

Over at #1542144: Mark strings as localizable/translatable (new t()-alike string function that isn't t(), only for potx) there is a suggestion to use annotations on the class property that holds translatable strings so they can be translated prior to display.

catch’s picture