Nazwa w jedną stronę, kod w drugą: dwa kierunki tekstu w interfejsie

Nazwa klienta wygląda poprawnie, dopóki obok nie pojawi się kod projektu. Nagle nawias stoi po innej stronie, znak plus odłącza się od numeru telefonu, a pracownik zaczyna przepisywać wartość ręcznie. Strona nie musi mieć arabskiej wersji językowej, żeby spotkać tekst czytany od prawej do lewej. Wystarczy formularz, do którego ktoś wpisze swoją nazwę.

Problem dotyczy relacji między znakami, a nie tylko wyboru pisma. Polski opis pola, nazwa w innym alfabecie, łaciński identyfikator i numer mogą znaleźć się w jednym wierszu. Każda część ma własny sens, a użytkownik powinien umieć odczytać i skopiować właściwą wartość. Projekt nie może oczekiwać, że sam naprawi kolejność, dostawiając spacje.

Wiersz składa się z kilku informacji

Przyjmijmy fikcyjny panel pracowni Rama, która obsługuje zamówienia od różnych organizatorów wystaw. Językiem panelu jest polski. W jednym zgłoszeniu nazwa organizacji została podana pismem arabskim, kod projektu ma postać RM-208-A, a osoba kontaktowa przekazała numer telefonu w zapisie międzynarodowym. Te trzy wartości trzeba zachować i rozpoznawalnie przedstawić.

Najpierw ustal strukturę: nazwa organizacji jest nazwą, kod identyfikuje projekt, a numer prowadzi do kontaktu. Nie sklejaj ich w jeden nieopisany fragment tylko dlatego, że mieści się on na szerokiej makiecie. Osobne etykiety albo wyraźne grupy mogą ułatwić rozpoznanie wartości również wtedy, gdy użytkownik nie czyta danego alfabetu. Nie zastępują jednak poprawnej obsługi kierunku tekstu.

Zachowaj relację etykiety z wartością także po zmianie układu. Jeśli na telefonie nazwa trafia nad kod, nie może wyglądać jak jego opis albo fragment nagłówka kolejnej pozycji. Przy kilku zgłoszeniach wyraźna granica kart pomaga uniknąć przypisania numeru do sąsiedniej organizacji. Zmiana kierunku nie powinna osłabiać zwykłego porządku informacji.

Unicode Bidirectional Algorithm, UAX #9 odróżnia logiczną kolejność znaków przechowywanego tekstu od kolejności prezentacji. Odczytana 30 października 2026 r. wersja dokumentu to rewizja 52 dla Unicode 18.0.0, datowana na 1 września 2026 r. Stan specyfikacji nie potwierdza identycznej obsługi w każdym używanym środowisku.

Dla Ramy oznacza to potrzebę dwóch kontroli. Pierwsza sprawdza, jak informacja wygląda w panelu. Druga porównuje wartość zachowaną i przekazaną dalej. Do porównania wartości potrzebny jest tekst, nie sam zrzut ekranu. Obraz pokazuje prezentację, ale nie pozwala ustalić zawartości pola po skopiowaniu. Zachowaj zatwierdzoną próbkę i sprawdź ją w kolejnych miejscach obiegu.

Nie odwracaj ręcznie liter, żeby naprawić jeden ekran. Taki zabieg może sprawić, że widok zacznie wyglądać znajomo osobie nieczytającej tekstu, lecz skopiowana treść przestanie odpowiadać oryginałowi.

Nie myl też kierunku z wyrównaniem. Przesunięcie całego pola do prawej krawędzi nie rozstrzyga relacji nazwy, nawiasu i numeru wewnątrz wartości. Podobnie wybór języka strony nie mówi, w jakim kierunku zapisano każdą nazwę przekazaną przez użytkownika. Wymagania trzeba opisać dla danych, które aplikacja rzeczywiście przyjmuje.

Przy wdrażaniu wersji językowych strony kontrolujesz między innymi spójność całej ścieżki. W polskiej wersji trzeba także odebrać fragmenty o przeciwnym kierunku zapisu. Nie odkładaj tej kontroli do chwili uruchomienia kolejnego rynku. Nazwa w formularzu może pojawić się wcześniej niż plan ekspansji.

Granica nazwy nie powinna znikać po dodaniu liczby

W nagłówku zgłoszenia panel pokazuje nazwę organizacji, myślnik i liczbę załączników. Nazwa jest niezależną wartością, a liczba opisuje inną informację. Jeśli projekt traktuje je jako jeden ciąg bez rozróżnienia części, niektóre kombinacje znaków mogą dać mylący układ. Odbiór powinien obejmować całe zestawienie, nie samą nazwę w pustym polu.

Wskazówki W3C o mieszaniu kierunków w HTML opisują otaczanie frazy odpowiednim znacznikiem z kierunkiem dir, a przy nieznanym kierunku między innymi dir="auto" lub element bdi. Chodzi o określenie granicy i kierunku fragmentu. Dobór mechanizmu należy do wdrożenia; samo przesunięcie tekstu na makiecie nie realizuje tych zaleceń.

W projekcie pokaż więc, które dane są jednym fragmentem, a które mają pozostać odrębnymi wartościami. Licznik plików powinien pozostać rozpoznawalnie oddzielony od nazwy klienta. Kod projektu powinien być rozpoznawalny razem z łącznikami, a nie jako luźne cyfry dopisane do nazwy. Tę strukturę przekaż wykonawcy razem z próbkami danych, zamiast zostawiać mu sam zrzut poprawnego przypadku.

Przy nazwie pochodzącej od użytkownika nie zakładaj stałego kierunku na podstawie jednego rekordu. W następnym zgłoszeniu może pojawić się nazwa łacińska, mieszana albo zaczynająca się od cyfr. W3C opisuje automatyczny kierunek oparty na pierwszym silnym znaku kierunkowym. Nie oznacza to odgadnięcia języka ani intencji każdej złożonej nazwy; trudniejsze przykłady nadal wymagają odbioru.

Przygotuj kilka rodzajów zestawień:

• Nazwa w innym kierunku obok polskiej etykiety i numeru zgłoszenia.
• Nazwa zawierająca także łacińską część, cyfrę lub znak interpunkcyjny.
• Kod z łącznikami albo nawiasami, przedstawiany osobno oraz przy nazwie.
• Numer telefonu z plusem i odstępami, widoczny jako tekst oraz jako działanie kontaktowe.
• Krótka lista dwóch nazw rozdzielonych przecinkiem, z osobnym licznikiem wyników.

Każdy przypadek powinien mieć uzgodnioną wartość źródłową i oczekiwany sposób odczytania. Osoba znająca właściwy język potwierdza nazwy i ich sens. Projektant oraz wykonawca sprawdzają strukturę, prezentację i działanie interfejsu. To współpraca przy odbiorze, a nie zastępowanie kompetencji językowych wizualną intuicją.

Przygotuj również wzorzec dla osoby, która nie zna danego alfabetu, ale obsługuje zgłoszenie. Powinna rozpoznawać etykiety, kod i właściwe działanie bez przepisywania nazwy na własny sposób. Nie wymagaj samodzielnej transliteracji, czyli zapisywania jej znakami innego alfabetu, jeśli proces ma zachować oryginalną wartość. Źródło ewentualnej dodatkowej nazwy pomocniczej uzgodnij osobno.

Nie zakładaj, że jeden poprawny przypadek rozstrzyga wszystkie pozostałe. Zmiana etykiety, dopisanie nawiasu albo liczby może ujawnić problem niewidoczny przy samej nazwie. Przykłady w dokumentacji pokazują mechanizm; własna próba powinna obejmować rzeczywistą budowę nagłówków, wyników wyszukiwania i potwierdzeń używanych przez Ramę.

Dłuższą nazwę sprawdź po zawinięciu do kolejnego wiersza. Projekt długich tekstów w interfejsie pomaga zachować potrzebny zakres, lecz tutaj dochodzi relacja kierunków. Ucięcie końcówki może usunąć część pozwalającą odróżnić dwa podmioty. Użytkownik powinien mieć dostęp do pełnej wartości w uzgodniony sposób.

Sprawdź także sam kod po skróceniu. Wartości RM-208-A i RM-208-B różnią się końcówką; podgląd pokazujący wyłącznie początek ukryje rozstrzygającą część. Rozwinięcie pełnej wartości powinno działać również bez najechania myszą. Przyciski wyboru lub kopiowania mają dotyczyć całego identyfikatora, a nie tylko znaków pozostawionych w krótkiej etykiecie.

Wpisanie, wybór i skopiowanie to osobne chwile

Formularz przyjmuje nazwę, potem pokazuje ją w podsumowaniu, a następnie w wyniku wyszukiwania. Każdy widok może mieć inną strukturę otoczenia. Dlatego nie kończ próby na polu edycji. Przejdź całą drogę aż do miejsca, z którego pracownik przygotowuje odpowiedź lub przekazuje sprawę dalej.

W polu sprawdź wpisywanie i wklejanie zatwierdzonej próbki. Użytkownik powinien umieć zaznaczyć fragment, poprawić go i wrócić do dalszej pracy. Jeżeli interfejs proponuje podpowiedzi, sprawdź rozpoznawalność pełnej nazwy oraz kodu. Wybór konkretnego rekordu z pola podpowiedzi nie może zostać zastąpiony samym podobieństwem widocznego tekstu.

Odbierz również komunikat błędu. Jeśli nazwa nie przechodzi walidacji, użytkownik powinien poznać rzeczywistą przyczynę i dopuszczony sposób poprawy. Ogólne „użyj prawidłowych znaków” może sugerować, że sam alfabet jest niedozwolony, choć problemem bywa inna reguła pola. Zakres przyjmowanych danych ustal świadomie i sprawdź ze sposobem ich późniejszego przechowywania.

Oddziel próbę wyglądu od próby kopiowania. Pracownik kopiuje kod RM-208-A i wkleja go w kontrolowane pole porównawcze. Odbierający sprawdza, czy zachowano właściwą wartość i kolejność znaków. Następnie porównuje kopię całego wiersza: nazwy, kodu i dodatkowej informacji. Obie czynności mogą dawać inny zakres tekstu, co trzeba jasno pokazać w etykiecie przycisku.

Przycisk „Kopiuj kod” powinien pobierać kod, nie układ całej karty. „Kopiuj dane kontaktowe” obejmuje inny zestaw. Jeżeli działanie dodaje etykiety lub usuwa formatowanie, ustal to i pokaż w próbce. Niech odbiór porówna rezultat w miejscu docelowym, zamiast poprzestać na zielonym znaczku przy przycisku.

Po wklejeniu nazwy do innego formularza wykonaj ponowny odczyt zapisanego zgłoszenia. Poprawny schowek nie potwierdza, że kolejna aplikacja zachowała wartość. Jeśli w obiegu występuje ręczna korekta, zapisz jej powód i sprawdź, czy nie naprawia wyłącznie wyglądu kosztem danych. Dzięki temu wskażesz miejsce, w którym zmieniła się wartość, zamiast poprawiać ponownie wszystkie widoki.

Przy numerze telefonu sprawdź również zgodność widocznej wartości z celem działania kontaktowego. Ładny zapis nie potwierdza, że przycisk używa właściwego numeru. Do próby przygotuj dane kontrolowane i warunki, w których nie dochodzi do połączenia z przypadkową osobą. Projekt powinien odróżniać kopiowanie wartości od uruchomienia kontaktu.

Jeśli organizacja korzysta z odczytu głosowego lub generowanych komunikatów, osobno odbierz wymowę nazw i jednostek. Poprawna kolejność na ekranie nie potwierdza poprawnej wymowy. Zachowaj granicę między tymi próbami, żeby dobry wynik jednej nie zasłonił braku drugiej.

Sprawdź dane także poza szerokim ekranem

Na telefonie nagłówek zajmuje więcej wierszy, przyciski przechodzą pod nazwę, a kod może zostać skrócony. Nie oceniaj tego wyłącznie przez zmniejszenie makiety. W działającej wersji sprawdź zawijanie, pełny podgląd i kopiowanie. Wybierz rzeczywiste przeglądarki oraz urządzenia objęte zakresem wdrożenia, zamiast deklarować obsługę każdego możliwego środowiska.

Eksport do pliku i wiadomość potwierdzająca wymagają oddzielnego sprawdzenia. Dokument może składać tekst innym mechanizmem niż strona. Ustal, które miejsca należą do dostarczanego zakresu i kto odpowiada za ich odbiór. W raporcie rozdziel wynik panelu od wyniku wygenerowanego dokumentu, nawet gdy oba korzystają z tych samych danych.

Dla każdego miejsca zachowaj tę samą paczkę kontrolną: wartość źródłową, opis otoczenia i oczekiwany zakres kopiowania. Przy poprawce powtórz konkretny przypadek oraz pozostałe miejsca korzystające ze zmienionego komponentu. Po naprawie nagłówka sprawdź ponownie numer w podsumowaniu oraz zapis na liście wyników. Zapisz również środowiska, których nie objęto próbą.

Jeżeli nazwy przechodzą przez AI lub tłumaczenie, zachowaj materiał źródłowy do porównania. Kontrola tłumaczenia dokumentów dotyczy również zgodności nazw i identyfikatorów. Błąd wyglądu nie musi oznaczać zmiany przechowywanej wartości, a rzeczywista zmiana wartości nie zawsze będzie widoczna w krótkim podglądzie. Trzeba rozstrzygnąć oba pytania.

Wymagania dla Aeneia Design można opisać bez gotowej technicznej recepty: ta nazwa, ten kod i ten numer mają pozostać rozpoznawalne w formularzu, podsumowaniu i kopii. Zatwierdzone próbki oraz opis celu pozwalają zbudować sprawdzalny zakres projektu. Pracownik ma zająć się zgłoszeniem. Przestawianie nawiasów nie powinno zostać jego dodatkową specjalizacją.