Strategia lokalizacji dla App

1. Dlaczego w ogóle myśleć o lokalizacji właśnie w ChatGPT App

Jeśli tworzyliście zwykłe aplikacje webowe, lokalizacja najpewniej kojarzyła się wam z klasycznym i18n: ciągi interfejsu, kilka formatów dat i liczb, słowniki — i starannie wszystko tłumaczycie. W ChatGPT App jest ciekawiej: pojawia się uczestnik numer trzy — sama LLM. Czyta wasze opisy narzędzi, prompty, wyniki, wyciąga wnioski i podejmuje decyzje.

Czyli język to nie tylko „jak ładnie pokazać tekst użytkownikowi”, ale i „jak model zrozumie, co robi wasz tool, kiedy go wywołać i jakie argumenty tam podstawić”. Przycisk „Kup” można przetłumaczyć tak sobie — użytkownik się domyśli. Ale jeśli nieprecyzyjnie opiszecie tool, który wykonuje płatność, w mieszance rosyjskiego i angielskiego, model może albo nigdy go nie wywołać, albo wywołać zupełnie nie tak, jak oczekiwaliście.

Jeszcze jeden moment: ChatGPT już przekazuje do waszego serwera MCP wskazówki o lokalizacji i lokacji użytkownika — _meta["openai/locale"] i _meta["openai/userLocation"]. Dzieje się to na poziomie zapytań MCP do narzędzi, abyście mogli dopasować tekst i dane do języka oraz regionu użytkownika. Czyli platforma już „podsuwia” wam kontekst, a zadaniem dewelopera jest rozważnie z niego skorzystać.

Dlatego w tym module patrzymy na lokalizację jako na aspekt architektoniczny ChatGPT App, a nie jako na „przetłumaczyliśmy UI i zapomnieliśmy”.

2. Warstwy, które trzeba zlokalizować

Spójrzmy na App jak na warstwowy tort. Każda warstwa może (i często powinna) być lokalizowana. Żeby nie utonąć, zacznijmy od mapy.

Przegląd warstw

Najpierw ogólna tabela, a potem rozbijemy na kawałki.

Faktycznie to pierwsza warstwa naszej mapy lokalizacji: dalej dodamy głębię (kosmetyka/semantyka), języki i konkretne elementy.

Teraz przejdźmy przez warstwy po kolei.

Widget UI

Najbardziej oczywista warstwa — interfejs widżeta. W GiftGenius to:

• nagłówki bloków;
• etykiety pól („Odbiorca”, „Budżet”, „Zainteresowania”);
• przyciski („Dobierz prezent”, „Wyczyść filtry”);
• podpowiedzi w inputach („np. kolega, mama…”);
• komunikaty o błędach i pustych stanach („Nie znaleziono prezentów”).

W zwykłej aplikacji React to pierwsi kandydaci do wyniesienia do słowników. Tu jest tak samo, tylko z poprawką na to, że UI to nie cały App, a jedynie jedno z jego „oblicz”.

Nieco później w module zrobimy porządną architekturę i18n dla widżeta, ale już teraz ważne jest ustalić: ciągów tekstowych nie powinno być w JSX. Nawet jeśli na razie wspieracie jeden język, wygodnie od razu strukturyzować teksty UI.

Mini‑przykład z naszym GiftGenius (na razie bez prawdziwej biblioteki i18n):

type Locale = "en" | "ru";

const uiText = {
  en: {
    title: "GiftGenius: find a perfect present",
    recipientLabel: "Recipient",
  },
  ru: {
    title: "GiftGenius: dobierz idealny prezent",
    recipientLabel: "Odbiorca",
  },
};

function GiftForm({ locale }: { locale: Locale }) {
  const t = uiText[locale];

  return (
    <div>
      <h2>{t.title}</h2>
      <label>{t.recipientLabel}</label>
      {/* pozostałe pola */}
    </div>
  );
}

Tutaj nie robimy jeszcze „prawdziwej” lokalizacji, ale już wyraźnie wydzielamy warstwę tekstów UI.

Teksty GPT i prompty

Kolejna warstwa — systemowe i pomocnicze teksty, które nie są widoczne bezpośrednio dla użytkownika, ale silnie wpływają na zachowanie modelu:

• system‑prompt waszego App („Jesteś asystentem do doboru prezentów…”);
• szablony wyjaśnień, które dajecie modelowi („Sporządź krótkie podsumowanie wyboru”);
• przygotowane follow‑upy i podpowiedzi dla modelu („zaproponuj użytkownikowi doprecyzowanie budżetu, jeśli…”).

Te teksty też mogą (i często powinny) być lokalizowane. Prosty przykład: jeśli użytkownik pisze po rosyjsku, a system‑prompt macie w całości po angielsku, model oczywiście sobie poradzi, ale pozbawiacie się dokładnej kontroli nad stylem i sformułowaniami dla tego języka.

Nieco później, w lekcjach o narzędziach lokalizacji promptów i opisów (prompts/descriptions), zobaczymy, jak umiejętnie grać wielojęzycznymi system‑promptami. Tutaj ważne jest zaznaczyć: prompty to tak samo lokalizowalna warstwa jak UI.

Dane i content

Dalej idą wasze dane. Dla GiftGenius to katalog prezentów: nazwy, opisy, kategorie, czasem wskazówki jak używać prezentu. Dla komercyjnego App to także ceny, waluty, jednostki miary, formaty dat itd. W specyfikacjach product feed dla ChatGPT (format, w którym opisujecie swoje produkty i usługi dla platformy) te pola tekstowe (title, description) i ceny są wyraźnie wydzielone, by można je było poprawnie wyświetlać użytkownikom w ChatGPT.

Jeśli chcecie globalny App, dla katalogu prezentów pojawiają się co najmniej takie pytania:

• czy przechowujemy nazwy/opisy w wielu językach;
• jak wybieramy, który język zwrócić użytkownikowi;
• co robimy, jeśli tłumaczenia jeszcze nie ma (fallback);
• jak pokazujemy waluty i formaty dat/cen dla różnych regionów.

Niewielki, typowany przykład dla katalogu:

type Locale = "en" | "ru";

interface LocalizedString {
  en: string;
  ru: string;
}

interface Gift {
  id: string;
  title: LocalizedString;
  description: LocalizedString;
  priceCents: number;
  currency: "USD" | "EUR" | "RUB";
}

function getLocalizedTitle(gift: Gift, locale: Locale) {
  return gift.title[locale] ?? gift.title.en;
}

Czyli lokalizacja to nie tylko frontend, ale i struktura danych w bazie oraz w zasobach MCP. Wrócimy do tego, gdy będziemy mówić o Gateway (bramie między ChatGPT i waszymi usługami) oraz serwerze MCP.

Opisy tools i JSON Schema

Czwarta warstwa — opisy narzędzi i ich argumentów. Właśnie przez nie model rozumie, kiedy trzeba wywołać wasz tool i jakie przekazać argumenty. W MCP to title, description narzędzia oraz description dla pól schematu JSON.

Dokumentacja Apps SDK podkreśla, że model wykorzystuje nazwy, opisy i dokumentację parametrów, by wybierać narzędzia i budować argumenty.

Umowny przykład narzędzia GiftGenius w serwerze MCP w TypeScript:

server.registerTool(
  "suggest_gifts",
  {
    title: "Suggest gifts",
    description: "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: {
      type: "object",
      properties: {
        recipient: {
          type: "string",
          description: "Who is the gift for (e.g. mother, colleague)?",
        },
      },
      required: ["recipient"],
    },
  },
  async ({ input }) => { /* ... */ }
);

Teraz wszystko jest po angielsku — model świetnie to rozumie. Ale co, jeśli użytkownik pisze po rosyjsku? Nadal zwiąże „mama” z recipient, ale przy bardziej złożonych polach i terminach domenowych rośnie ryzyko pomyłki. W lekcji o strategiach lokalizacji opisów osobno omówimy: jeden angielski język opisów kontra opisy zlokalizowane.

Na tym etapie w mapie lokalizacji ważne jest po prostu zaznaczyć: opisy tools i JSON Schema także mogą być lokalizowane i to wpływa na zachowanie modelu.

Commerce i część prawna

Wreszcie warstwa, o której często przypomina się na samym końcu — wszystko, co związane z pieniędzmi i tekstami prawnymi:

• nazwy SKU i planów subskrypcji;
• pola title/description w feedach commerce (produkty, usługi, subskrypcje);
• Terms of Service, Privacy Policy, Refund Policy;
• maile i powiadomienia (email, push), jeśli App coś wysyła poza ChatGPT;
• statusy zamówień i błędy płatności, które pokazujecie użytkownikowi („Płatność odrzucona”, „Niedostępne w twoim regionie”).

Są tu dwa aspekty: UX i prawo. Użytkownik powinien rozumieć, na co się zgadza i za co płaci, we własnym języku. Jednocześnie tłumaczenia muszą być poprawne prawnie: czasem prawnicy wymagają, aby za prawnie wiążące uznawać tylko teksty w jednym języku (np. po angielsku), a inne tłumaczenia miały charakter „referencyjny”.

W naszej mapie lokalizacji koniecznie zaznaczamy commerce i treści prawne jako oddzielną warstwę, ponieważ często potrzebny jest dla nich inny proces (prawnicy, compliance, uzgadnianie tekstów z marketingiem).

3. Głębia lokalizacji: „kosmetyka” kontra „semantyka”

Gdy mówimy „zlokalizować App”, warto rozróżniać dwa poziomy głębokości: kosmetyczny i semantyczny.

Kosmetyczna lokalizacja

Kosmetyka — to wszystko, co zmienia wygląd i czytelność, ale prawie nie zmienia zachowania systemu. Przykłady:

• przetłumaczone nagłówki i etykiety na przyciskach;
• przetłumaczone placeholders w inputach;
• „ludzkie” komunikaty o błędach w UI;
• zlokalizowany tekst banera marketingowego w widżecie.

Dla klasycznych aplikacji webowych często na tym się kończy. W ChatGPT App to ważna, ale tylko górna część góry lodowej.

Semantyczna lokalizacja

Semantyka — to rzeczy, od których zmienia się zachowanie modelu i logika App. Tutaj język wpływa na:

• to, które narzędzie model wybierze;
• to, jak wypełni argumenty narzędzia;
• to, jakie dane uzna za „właściwe” dla danego użytkownika.

Przykłady semantycznej lokalizacji:

• system‑prompt w języku użytkownika, nadający styl i zasady rozmowy;
• opisy tools i ich pól w języku, w którym komunikuje się użytkownik;
• różne teksty podpowiedzi/instrukcji w zależności od kontekstu kulturowego;
• ustawienia formatów dat/walut, wpływające na parsowanie i generację (31.12.2025 vs 12/31/2025).

Jeśli zlokalizowaliście tylko kosmetykę, ale nie semantykę, wasz App może wyglądać na zlokalizowany, ale pod spodem zachowywać się jak „anglojęzyczny”. W mapie lokalizacji warto wprost oznaczyć, które elementy są krytyczne dla zachowania modelu.

Dla naszego GiftGenius to na przykład:

• opis pola budget w JSON Schema („Budget in the user’s currency”) — semantyka;
• etykieta przycisku „Dobierz prezent” — kosmetyka (ważna dla UX, ale model jej nie widzi).

Skoro rozróżniamy kosmetykę i semantykę, logicznie odpowiedzieć na pytanie: na ilu językach w ogóle chcecie, aby App działał.

4. Jednojęzyczny vs wielojęzyczny ChatGPT App

Zanim narysujemy mapę, trzeba określić ambicje: tworzycie ściśle jednojęzyczny App czy celujecie w wielojęzyczną publiczność.

Jednojęzyczny App

Jednojęzyczny App — to wariant, w którym świadomie wspieracie tylko jeden język. Na przykład tylko angielski.

UI‑widżet, prompty, opisy narzędzi i dane — wszystko w jednym języku. To mocno upraszcza życie:

• jedna baza kodu bez rozwidleń po językach;
• jeden schemat katalogu (bez title_en, title_ru i podobnych);
• łatwiej utrzymywać i testować.

Ale oczywiście publiczność jest ograniczona. W przypadku ChatGPT App oznacza to też: jeśli użytkownik przyjdzie z inną lokalizacją, ChatGPT nadal może pokazać wasz App, ale będzie musiał ciągle „przekładać” język użytkownika na wewnętrzny język App. W niektórych niszach to okej, ale dla masowego konsumenckiego serwisu prezentowego — raczej nie.

Wielojęzyczny App

Wielojęzyczny App — to już decyzja architektoniczna. Tutaj:

• UI i teksty poprawnie wyświetlają się na podstawie locale użytkownika;
• dane (katalogi, opisy produktów) również są powiązane z językiem/regionem;
• opisy tools i system‑prompty mogą różnić się w zależności od języka;
• scenariusze commerce uwzględniają lokalne waluty, podatki, ograniczenia.

W takim przypadku jedno warunkowe if (locale === "ru") rozsiane po całym kodzie zdecydowanie nie wystarczy. Potrzebna jest architektura: słowniki, lokalizowalne zasoby, jedno miejsce, w którym przechowywane i przetwarzane są locale i userLocation, ustalenia między widżetem a serwerem MCP.

Dokumentacja Apps SDK wprost podkreśla, że ChatGPT przekazuje wam w _meta locale i userLocation, gdy wywołuje wasze narzędzia — właśnie po to, byście mogli po stronie serwera wybierać właściwy język i format danych. To jest „paliwo” dla wielojęzycznych App.

Małe porównanie

Dla wizualizacji — mini‑porównanie:

Na poziomie kursu będziemy wychodzić z założenia, że GiftGenius staje się wielojęzyczny (co najmniej EN/RU), żeby pokazać „dorosły” schemat. Wiele zabiegów przyda się jednak również w uporządkowanym jednojęzycznym App, jeśli chcecie być gotowi na rozszerzenie.

5. Gdzie język realnie wpływa na model

Wyróżnijmy teraz punkty, w których język bezpośrednio wpływa na zachowanie ChatGPT.

Język user input vs język descriptions tools

Wyobraźmy sobie:

• użytkownik pisze: „Dobierz prezent dla kolegi na 50 euro”;
• wasz tool suggest_gifts jest opisany wyłącznie po angielsku;
• pola schematu: recipient, budget, currency, interests.

Model musi:

1. zdecydować, że w ogóle trzeba wywołać suggest_gifts;
2. wyekstrahować recipient = "colleague", budget = 50, currency = "EUR";
3. poprawnie zserializować to do argumentów JSON.

Jeśli opisy są krótkie i w innym języku, model sobie poradzi, ale rośnie prawdopodobieństwo błędnego wypełnienia pól. Na przykład pomylić budget z price_limit albo przekazać tekst w polu interests, bo w opisie pola było coś mglistego typu „Any extra info about the gift”.

Dla rosyjskiego tekstu użytkownika i angielskich descriptions model dodatkowo ciągle „przeskakuje” między językami.

Wariant ze zlokalizowanym schematem:

const locale = _meta?.["openai/locale"] ?? "en"; // przychodzi od ChatGPT 
const isRu = locale.startsWith("ru");

server.registerTool(
  "suggest_gifts",
  {
    title: isRu ? "Dobór prezentów" : "Suggest gifts",
    description: isRu
      ? "Dobierz 3–5 pomysłów na prezenty na podstawie profilu odbiorcy."
      : "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: { /* ... */ },
  },
  async ({ input }) => { /* ... */ }
);

Tu upraszczamy: w rzeczywistości opisy lepiej generować raz przy starcie serwera, a nie przy każdym wywołaniu, ale idea jest jasna. Możemy zwracać ChatGPT różne opisy w zależności od locale, aby modelowi było łatwiej rozumieć użytkownika.

Język danych vs język zapytania

Jeśli wasz katalog prezentów jest tylko po angielsku, a użytkownik rozmawia po rosyjsku, model będzie dobierał anglojęzyczne nazwy i opisy. Czasem to w porządku, czasem — nie. Ważniejsze jest jednak to, jak formatujecie wynik:

• czy pokazujecie użytkownikowi oryginalne titles/description z serwera;
• czy model streszcza je w swoim tekście w języku użytkownika;
• czy wasz tool sam zwraca już zlokalizowany tekst na podstawie locale.

W Apps SDK structured content (ustrukturyzowane dane, które zwracacie z tools) i odpowiedź tekstowa mogą żyć osobno. Możecie zwrócić ustrukturyzowane dane (np. JSON z polami produktu) i osobny tekst dla użytkownika, a model dalej zdecyduje, jak to wyrenderować lub streścić.

Lokalizacja może następować na poziomie serwera (dane) lub na poziomie modelu (przeformułować w potrzebnym języku). Przy tworzeniu mapy warto zdecydować, gdzie dokładnie chcecie trzymać „ostatnią instancję”.

System‑prompt i follow‑ups

Jeśli system‑prompt macie tylko po angielsku, a użytkownik — rosyjskojęzyczny, model będzie stale balansował między dwoma językami. To może być w porządku, ale czasem chcecie sztywno ustawić ton: np. w polskiej wersji App chcecie bardziej nieformalny styl, a w angielskiej — formalny.

W związku z tym w mapie lokalizacji trzeba zaznaczyć:

• system‑prompt EN;
• system‑prompt RU;
• szablony follow‑ups (EN/RU);
• dowolne „twarde” podpowiedzi w promcie dla narzędzi.

6. Mapa lokalizacji dla GiftGenius

Zbierzmy teraz wszystko, co omówiliśmy o warstwach, głębi i językach, w jawną mapę lokalizacji dla GiftGenius. Zróbmy to, co potem zrobicie dla swojego App: sporządźmy mapę lokalizacji. Idea jest prosta: tabela, w kolumnach — warstwa i typ encji, w wierszach — konkretne elementy.

Przykład mapy

Oto uproszczona mapa dla GiftGenius (EN/RU):

suggest_gifts.description

budget.description

Po lewej grupujemy według warstw, dalej — konkretne elementy. Ostatnia kolumna pomaga rozumieć, czego nie można zmieniać bez uzgodnień z projektantem promptów/osobą od modeli: wszystko, co oznaczone jako semantyka, wpływa na zachowanie GPT.

Mały szkic kodu

Aby powiązać mapę z kodem, można wprowadzić prosty typ dla lokalizowalnych encji:

type LocalizedTextKey =
  | "ui.title"
  | "ui.recipient_label"
  | "error.no_gifts"
  | "prompt.summary_intro";

type Locale = "en" | "ru";

type Messages = Record<Locale, Record<LocalizedTextKey, string>>;

const messages: Messages = {
  en: {
    "ui.title": "GiftGenius: find a perfect present",
    "ui.recipient_label": "Recipient",
    "error.no_gifts": "No gifts found",
    "prompt.summary_intro": "Here’s why these gifts fit:",
  },
  ru: {
    "ui.title": "GiftGenius: dobierz idealny prezent",
    "ui.recipient_label": "Odbiorca",
    "error.no_gifts": "Nie znaleziono prezentów",
    "prompt.summary_intro": "Oto dlaczego te prezenty pasują:",
  },
};

Te same klucze można następnie wykorzystać zarówno w widżecie, jak i przy formowaniu promptów na serwerze (o ile przenosicie locale przez cały stos — o tym będzie następna lekcja). W ten sposób wasza „mapa lokalizacji” stopniowo zamienia się w typowany słownik, a nie w rozproszony zbiór ciągów.

7. Praktyka: stwórz mapę lokalizacji dla swojego App

Zanim zagłębimy się w konkretne techniki i18n i architekturę Gateway/MCP, ważne jest wykonać jedno nudne, lecz bardzo pożyteczne ćwiczenie: uczciwie opisać, co dokładnie zamierzacie lokalizować.

Dobrym podejściem jest otworzyć dowolny edytor (choćby Google Sheets lub Notion) i założyć tabelę z kolumnami:

• kategoria/warstwa (UI, prompty, dane, tools, commerce i część prawna, błędy);
• element (konkretny przycisk, konkretny opis pola, konkretny endpoint z tekstem);
• przykład wartości EN;
• przykład wartości w drugim języku (jeśli już jest albo chociaż szkic);
• oznaczenie „kosmetyka/semantyka/prawnie ważne”;
• właściciel (kto odpowiada za zmiany: frontend, serwer MCP, product, prawnik).

Następnie przechodzicie przez swój App i uczciwie wypisujecie wszystko, gdzie jest tekst albo gdzie język wpływa na format danych.

Dla GiftGenius wyszłaby mniej więcej rozszerzona wersja tabeli powyżej. Po drodze niemal na pewno odkryjecie parę „ukrytych” miejsc:

• stałe tekstowe w kodzie serwerów MCP (np. komunikaty o błędach);
• wartości domyślne w structuredContent (np. kategorie, których nie wyświetlaliście w UI);
• stare etykiety tools, które już nie odpowiadają ich faktycznemu zachowaniu.

To ćwiczenie szczególnie warto zrobić przed tym, jak połączycie lokalizację z realnym procesem biznesowym (płatności, aktywacje subskrypcji, dokumenty prawne). Zmienianie nazwy toola charge_user w wielojęzycznym systemie z ACP i tekstami prawnymi później boli dużo bardziej.

Ogólnie, jeśli wcześniej rysujecie mapę lokalizacji i uczciwie zaznaczacie, co dokładnie i w jakich językach zamierzacie wspierać, bardzo oszczędzacie sobie nerwy w kolejnych modułach — gdy do gry wejdą MCP, Gateway, commerce i Store.

8. Typowe błędy przy planowaniu lokalizacji

Błąd nr 1: uważać, że lokalizacja = „przetłumaczyć przyciski”.
Bardzo częsty scenariusz: zespół starannie wynosi wszystkie ciągi UI do słowników, tłumaczy je i cieszy się. Tymczasem system‑prompt zostaje tylko po angielsku, opisy tools — również, a katalog produktów zawiera wyłącznie anglojęzyczne nazwy. W rezultacie App wygląda na zlokalizowany, ale model w środku wciąż żyje w swoim świecie, a zachowanie pozostaje anglocentryczne. W praktyce objawia się to dziwnymi rekomendacjami i błędami w argumentach tools.

Błąd nr 2: nierozróżnianie kosmetyki i semantyki.
Czasem product prosi „nieco poprawić sformułowanie” w opisie narzędzia albo w system‑prompcie i deweloper zmienia tekst, jakby to była zwykła etykieta UI. Ale description pola JSON Schema czy fraza w system‑prompcie to część kontraktu z modelem. Takie zmiany mogą radykalnie zmienić to, jak GPT wywołuje wasz tool. Jeśli wcześniej nie oznaczać elementów semantycznych w mapie lokalizacji, łatwo przypadkowo zepsuć zachowanie App.

Błąd nr 3: zaczynać od wielojęzycznego chaosu bez architektury.
Bardzo kusi na początku po prostu porozrzucać po kodzie if (locale === "ru") i podkładać rosyjskie ciągi tam, gdzie potrzeba. W rezultacie po kilku tygodniach aplikacja zamienia się w „lokalizacyjne piekło”: w jednym komponencie ciągi ze słownika, w drugim — zaszyte w JSX, na serwerze — trzecia konwencja nazewnicza kluczy. Późniejsze podłączenie normalnego systemu i18n i doprowadzenie wszystkiego do jednego ładu staje się dużo trudniejsze.

Błąd nr 4: zapominanie o danych i pieniądzach.
Nawet doświadczone zespoły często zaczynają od tłumaczenia UI i promptów, ale pomijają, że katalogi produktów, ceny, waluty i teksty prawne również muszą uwzględniać locale i userLocation. W specyfikacjach product feed dla ChatGPT właśnie twardo określono, jakie pola tekstowe i ceny są potrzebne do poprawnego wyświetlania towarów użytkownikowi. Jeśli nie założycie wielojęzyczności na poziomie danych, później będziecie musieli albo dublować feed, albo robić bolesne migracje.

Błąd nr 5: ignorowanie sygnałów platformy o lokalizacji i lokacji.
ChatGPT już przekazuje w wywołaniach MCP _meta["openai/locale"] i _meta["openai/userLocation"], abyście mogli rozumieć, w jakim języku i z jakiego regionu się z wami komunikuje. Niektórzy deweloperzy mimo to każą użytkownikowi „Wybierz język interfejsu” przy pierwszym uruchomieniu i w żaden sposób nie używają tych sygnałów do wyboru zasobów i cen. W rezultacie UX cierpi, a architektura staje się bardziej skomplikowana niż to konieczne.

Błąd nr 6: nieustalanie „właścicieli” lokalizowalnych elementów.
Gdy wszystko idzie w produkcję, okazuje się, że tłumaczenia rozeszły się po różnych osobach: frontendowcy poprawiają teksty UI, backendowcy — opisy tools, specjalista ML — system‑prompt, a prawnicy przysyłają zredagowane Terms. Jeśli w mapie lokalizacji nie wskazać, kto odpowiada za którą warstwę, zmiany zaczynają się gryźć, a niektóre teksty aktualizują się w jednym miejscu, a w innym już nie.