Add names of attributes translations

[orzechdev]

It introduces in translation views (product, variant and page translation views) the following:

• replaced numbers with names of attributes,
• added the possibility to translate plain text attributes (not only rich text).

Fixes #2400.

Backend: saleor/saleor#11028

Example to test: https://2400-add-names-of-attributes-translations.dashboard.saleor.rocks/translations/EL/products/UHJvZHVjdDo3Mg%3D%3D

PR intended to be tested with API branch: add-attribute-field-to-AttributeValueTranslatableContent-type

Screenshots

Pull Request Checklist

1. This code contains UI changes
2. All visible strings are translated with proper context including data-formatting
3. Attributes [data-test-id] are added for new elements
4. Changes are mentioned in the changelog
5. The changes are tested in different browsers and in light/dark mode

Test environment config

API_URI=https://add-attribute-field-to-attributevaluetranslatablecontent-type.api.saleor.rocks/graphql/
MARKETPLACE_URL=https://apps.saleor.io
SALEOR_APPS_ENDPOINT=https://apps.saleor.io/api/saleor-apps

Do you want to run more stable tests?

To run all tests, just select the stable checkbox. To speed up tests, increase the number of containers. Tests will be re-run only when the "run e2e" label is added.

1. stable
2. giftCard
3. category
4. collection
5. attribute
6. productType
7. shipping
8. customer
9. permissions
10. menuNavigation
11. pages
12. sales
13. vouchers
14. homePage
15. login
16. orders
17. products
18. app
19. plugins
20. translations
21. navigation
22. variants

CONTAINERS=1

[andrzejewsky]

Please try to avoid "as" assertions, if you cannot, please create a function with that but with returning expected type

[andrzejewsky]

Could you properly type this?

[orzechdev]

Sure, fixed

[andrzejewsky]

Suggested change

	attrVal.translation?.richText ||
	attrVal.translation?.plainText ||
	null,
	attrVal.translation?.richText || attrVal.translation?.plainText

[andrzejewsky]

i think there is no need for additional null cast, but please double check

[orzechdev]

Yes, it is, I checked it and it's not needed.

[andrzejewsky]

so, you repeat the same logic, a function perhaps, and reuse it?

[orzechdev]

Good idea, I added a function for it.

[andrzejewsky]

for comparisons (because you do them later) perhaps is better to have enums (but we don't use them), so a constant object?

const TranslationFieldType = {
  SHORT: 'short',
  LONG: 'long',
  RICH: 'rich'
} as const

[andrzejewsky]

then type === TranslationFieldType.RICH, and values type: typeof Object.values(TranslationFieldType)

[orzechdev]

Sure, might be better with constant object, I've changed it to it.

[orzechdev]

Just for further reference, there was discussion few months ago, about enums that we would prefer string literals and constant object with strings as you proposed in your comment. Enums have some drawbacks, may not be really type-safe, introduce excessive code into bundle size or require importing them in every moment we use them https://fettblog.eu/tidy-typescript-avoid-enums/

[krzysztofzuraw]

Suggested change

	type === "rich"
	type === TranslationFieldType.RICH

[orzechdev]

👍 Fixed

[szczecha]

@orzechdev Clicking on edit button is not working, when attributes do not have a translation yet.

steps:
Open the link to the translation provided in this PR https://2400-add-names-of-attributes-translations.dashboard.saleor.rocks/translations/EL/products/UHJvZHVjdDo3Mg%3D%3D
Change language
Try to edit translations for attributes

Edit button not working, and you can see skeleton instead of No translation yet text

[orzechdev]

@szczecha fixed.
@andrzejewsky There is a component TranslationFields which expects explicitly only undefined to show skeleton. Rich text although displays skeleton based on disabled, but other fields not. So I left null explicitly in translation: attrVal.translation?.richText || attrVal.translation?.plainText || null, to leave skeleton working as it was before.