Англійська для Strapi CMS

Розмови Strapi змішують редакційний словник (контент, чернетки, публікація) з словником розробника (типи контенту, заповнення, права), і обговорення, яке не чітко розділяє два, часто закінчується тим, що редактор контенту і розробник розмовляють один про одного про те, що виглядає як одна і та ж проблема.

Ключовий словник

** Тип вмісту ** — схема, яка визначає тип вмісту (наприклад, « Стаття » або « Продукт ») разом з його полями, створена на панелі адміністрування Strapi і використовується для створення як інтерфейсу адміністратора, так і API. “Ми додали новий тип вмісту Author з відношенням назад до Article, так що кожна стаття може бути пов’язана з біографією і профілем конкретного автора.”

** Тип збірки проти одного типу ** — тип збірки містить багато записів одного типу (наприклад, багато статей блогу); один тип містить лише один запис (наприклад, домашню сторінку або загальні параметри сайту). “Параметри домашньої сторінки є єдиним типом, оскільки існує тільки одна домашня сторінка, але Article є типом збірки, оскільки у нас є сотні окремих повідомлень.”

Populate — параметр запиту на REST або GraphQL API Strapi, який вказує, які пов’ язані поля (відносини, носій, компоненти) включити до відповіді, оскільки типово пов’ язані дані не повертаються. “В відповіді API не було зображення обкладинки статті і автора, тому що ми забувають додати populate для цих відносин — Strapi не включає пов’язані дані, якщо ви явно не запитаєте про це.”

** Чернетки і публікації ** — параметр потоку роботи для типу вмісту, який надає змогу редакторам зберігати неопубліковані зміни окремо від реальної, опублікованої версії, отже, чернетку можна редагувати без зміни того, що буде показано користувачам.

• « Переписку вже виправлено у чернетці, але вона ще не була опублікована, оскільки для цього типу вмісту увімкнено чернетку і опублікування, і ніхто не натискав кнопку « Опублікувати » після редагування. » *

** Роль і дозвіл ** — система Strapi для керування тим, які кінцеві точки API і дії типу вмісту (знайти, створити, оновити, вилучити) дозволяється виконувати кожній ролі користувача (наприклад, аутентифікованій або нетиповій ролі « Редактор »). “Виклик API повертав 403 не через помилку, а тому, що дозвіл ролі Public для дії find цього типу вмісту ніколи не був ввімкнений.”

Звичайні фрази

• «Чи відсутні ці дані, тому що це відносини, які не були заповнені, або вони насправді не існують на цьому записі?»
• Чи є це типом колекції або єдиним типом — скільки записів цей вміст повинен мати?»
• Чи є редагування видимим, тому що воно опубліковано, чи цей вміст все ще знаходиться в чернетці?
• Чи є це проблемою дозволів на роль, або ж сам тип вмісту неправильно налаштований?
• Чи має це нове поле жити на існуючому типі вмісту, чи йому потрібен власний пов’язаний тип вмісту?

Приклади висловлювань

Зневадження проблеми API з відсутніми даними: “Відповідь повертала статті без поля автора взагалі — не тому, що зв’язок був порушений, а тому, що populate=author відсутній у запиту.”

Пояснення рішення щодо моделювання вмісту: “Ми моделювали Testimonial як власний тип колекції замість повторюваного компонента всередині Homepage, оскільки ми хочемо повторно використовувати ті ж самі свідчення на декількох сторінках.”

Опис виправлення прав доступу у нотатки передачі: “Помилки 403 на API публічного блогу були вирішені за допомогою вмикання дозволів find і findOne для ролі Public на типі вмісту Article — вони ніколи не були ввімкнуті після створення типу.”

Професійні поради

• Використовуйте populate явно, коли пов’ язане поле відсутнє у відповіді API — це майже завжди справжня причина, а не пошкоджене відношення.
• Розрізняйте тип збірки від одиничного типу чітко, коли пропонуєте нову модель вмісту — вибір неправильного типу є поширеною помилкою на початку, яку важко змінити пізніше.
• Посилання ** чернетки і публікації ** безпосередньо, коли зміна вмісту « не з’ являється » — це параметр робочого потоку, а не помилка кешування, є найчастішим поясненням.
• Назвіть конкретну ролю і дозволу під час зневадження помилки доступу API — «дозволи порушені» набагато менш корисні, ніж «ролі Public не вистачає дозволу find на цей тип вмісту»

Практичні вправи

1. Поясніть різницю між типом збірки і типом окремого об’ єкта.
2. Описати, чому важливо заповнювати поля при запиті API Strapi на пов’ язані дані.
3. Напишіть речення, у якому поясните, що робить чернетка- і- публікація і чому вміст може ще не з’ явитися у режимі реального часу.

В практиці: покращення комунікації з Strapi

Будьмо чесними – вивчення нової технології – це одне; ефективне спілкування про неї в професійному середовищі – це зовсім інше. Для неангломовних носіїв англійської мови, які використовують Strapi CMS, розуміння нюансової фрази не просто про те, щоб знати правильний вираз для «типу колекції»; це про те, щоб передавати свої ідеї чітко і впевнено в оглядах коду, обговореннях Slack і описах Pull Request. Це про те, щоб продемонструвати, що ви розумієте * чому * щось робиться, а не тільки * як *.

Однією з найпоширеніших пасток є переклад з рідної мови. Фрази, які звучать природно в одному контексті, можуть бути незграбними або навіть вводять у оману в англійській технічній комунікації. Наприклад, сказати «Ми повинні зробити тип контенту більш гнучким» не відразу зрозуміло. Що означає «гнучкий» насправді? Чи потрібно додати нове поле? Інше відношення з іншим типом збірки? Такі фрази, як « поліпшити обробку даних » або « поліпшити структуру вмісту », часто є кращим вибором, оскільки вони запрошують до подальшого обговорення і роз’ яснюють ваші наміри. Аналогічно, уникати надто буквальних перекладів термінів Strapi - “контент елемент” є цілком прийнятним в англійській мові; не насильно перекладати, якщо це не відкидає мови природно в команді.

Іншою ключовою областю, на якій варто зосередитися, є конструктивне висловлювання незгоду. Просте « Це неправильно » в коментарі перегляду коду не допоможе. Замість цього спробуйте щось на зразок: «Я розумію ваш підхід, але я переживаю, що це може призвести до проблем з продуктивністю з більшими наборами даних. Можливо, ми могли б дослідити альтернативні стратегії індексування? » Це демонструє, що ви розглянули наслідки і пропонує перспективу, орієнтовану на рішення. Аналогічно, при описі змін в PR, уникайте нечітких тверджень. Будь конкретним про * чому * ви робите зміну - “Рефакторизована логіка перевірки полів для поліпшення цілісності даних” є набагато більш інформативним, ніж просто “Фіксована перевірка полів.”

Нарешті, пам’ятайте, що документація не тільки для кінцевих користувачів; вона також критична для внутрішнього спілкування. Ясні і короткі описи PR, добре задокументовані виклики API, і навіть продумані повідомлення Slack сприяють спільному розумінню проекту.

Ось приклад використання інтерфейсу командної рядки Strapi для створення нового типу збірки:

strapi plugin generate collectiontype my-new-collectiontype --name="My Collection" --singularName="my-collection" --pluralName="my-collections"

Цю команду, якщо її описати у запиті на завантаження, можна сформулювати так: « Створено новий тип збірки з назвою « Моя збірка » з іменами у однині і множини « моє- зібрання » і « мої- збірки », що надає нам змогу ефективно структурувати наші дані у Strapi. » У цій команді чітко вказано виконану дію і її мету.