Jak przygotować katalog branżowy obsługujący kilka wersji językowych nazw firm

Najwięcej problemów w wielojęzycznym katalogu firm nie powoduje samo tłumaczenie interfejsu. Trudność zaczyna się wtedy, gdy jedna spółka używa oficjalnej nazwy rejestrowej, skróconej marki, lokalnego zapisu alfabetem narodowym i kilku wersji przeznaczonych na rynki zagraniczne. Jeżeli wszystkie te warianty zostaną zapisane w jednym polu, katalog szybko zacznie tworzyć duplikaty, błędne adresy URL i wyniki wyszukiwania, których użytkownik nie potrafi przewidzieć.

Podstawowa zasada brzmi: firma jest jednym rekordem, ale może mieć wiele nazw. Nazwa nie powinna być identyfikatorem przedsiębiorstwa. Do tego służy wewnętrzny numer rekordu, a w polskich realiach dodatkowo NIP, KRS, REGON lub inny identyfikator właściwy dla danego kraju. Dzięki temu zmiana nazwy, tłumaczenia albo zapisu nie rozrywa powiązań z oddziałami, kategoriami, opiniami i danymi kontaktowymi.

Oddziel firmę od jej nazw i wersji językowych

Najbezpieczniejszy model danych składa się z co najmniej dwóch tabel: głównego rekordu firmy oraz powiązanych z nim nazw językowych. W prostym wdrożeniu struktura może wyglądać tak:

• companies: identyfikator firmy, kraj rejestracji, NIP lub odpowiednik, status publikacji, adres, współrzędne, kategorie;
• company_names: identyfikator firmy, kod języka, nazwa wyświetlana, nazwa skrócona, wariant do wyszukiwania, status weryfikacji;
• opcjonalnie company_aliases: historyczne nazwy, marki, transliteracje i popularne błędne zapisy.

Kod języka powinien opierać się na standardzie BCP 47 albo przynajmniej na kodach ISO, np. pl, de, en, cs. Sam język nie zawsze wystarcza. W większym katalogu przydadzą się oznaczenia regionalne, takie jak en-GB, en-US, pt-PT i pt-BR, ponieważ ta sama nazwa opisowa lub forma prawna może być prezentowana inaczej na różnych rynkach.

Nie należy natomiast tworzyć w tabeli firmy kolumn name_pl, name_en, name_de, name_fr. Taki układ wydaje się wygodny przy dwóch językach, ale zaczyna przeszkadzać przy piątym. Każda nowa wersja wymaga wtedy zmiany schematu bazy, formularzy, eksportów i integracji API. Oddzielna tabela pozwala dodać kolejny język bez przebudowy całego systemu.

Trzeba też rozróżnić trzy rodzaje nazw:

1. Nazwa rejestrowa – dokładnie taka, jak w KRS, CEIDG albo zagranicznym rejestrze.
2. Nazwa handlowa – używana na szyldzie, stronie internetowej i w reklamach.
3. Nazwa lokalizowana – dostosowana do języka odbiorcy, o ile przedsiębiorstwo faktycznie jej używa.

Tego rozróżnienia nie wolno zastępować automatycznym tłumaczeniem. „Zakład Usług Komunalnych Sp. z o.o.” nie powinien bez zgody właściciela stawać się „Municipal Services Company Ltd.”. Taki zapis może być pomocnym opisem działalności, ale niekoniecznie poprawną nazwą podmiotu. Naz własnych zasadniczo się nie tłumaczy, chyba że firma posługuje się zatwierdzonym odpowiednikiem.

W formularzu administracyjnym warto więc dodać osobne pola:

• nazwa oficjalna;
• nazwa prezentowana;
• nazwa skrócona;
• język;
• alfabet;
• źródło lub osoba zatwierdzająca;
• data ostatniej weryfikacji;
• znacznik „nazwa domyślna”.

Najbardziej irytującym elementem takiego systemu jest obsługa braków. Część firm nigdy nie dostarczy nazw we wszystkich językach. Katalog musi zatem mieć jednoznaczną kolejność zastępowania: najpierw wersja wybrana przez użytkownika, następnie język domyślny firmy, a na końcu nazwa rejestrowa. Bez tej reguły różne części serwisu mogą wyświetlać tę samą firmę pod innymi nazwami.

Ustal reguły wyszukiwania, duplikatów i adresów URL

Wielojęzyczny katalog powinien przechowywać nazwę w oryginale, ale wyszukiwać także po jej znormalizowanej wersji. Normalizacja może obejmować zmianę wielkości liter, ujednolicenie odstępów, usunięcie części znaków interpunkcyjnych oraz utworzenie wariantu bez polskich znaków.

Przykładowo użytkownik powinien znaleźć „Łódzkie Centrum Narzędzi” po wpisaniu:

• Łódzkie Centrum Narzędzi;
• lodzkie centrum narzedzi;
• centrum narzędzi łódź;
• poprawnie przypisanego aliasu lub dawnej nazwy.

Nie oznacza to jednak, że wersja bez znaków diakrytycznych powinna zastępować oryginał. Normalizacja służy wyszukiwaniu, nie prezentacji. Na stronie firmy nadal należy pokazywać prawidłowy zapis „Łódzkie”, „München”, „České Budějovice” czy „Société”.

Przy alfabetach innych niż łaciński potrzebna jest transliteracja. Dla firmy zapisanej cyrylicą, alfabetem greckim albo ukraińskim warto przechowywać:

• nazwę oryginalną;
• oficjalną wersję łacińską, jeżeli istnieje;
• techniczny wariant transliterowany do wyszukiwarki;
• dodatkowe aliasy używane przez klientów.

Transliteracji nie należy generować ponownie przy każdym wyświetleniu strony. Lepiej zapisać ją w bazie i umożliwić korektę redakcyjną. Automatyczne biblioteki dobrze radzą sobie z typowymi przypadkami, ale potrafią stworzyć zapis, którego firma nigdy nie używała.

Osobnym problemem są duplikaty. Porównanie samych nazw nie wystarcza, ponieważ w jednym mieście mogą działać firmy „Auto-Serwis”, „Auto Serwis” i „AutoSerwis”. Z kolei ta sama spółka może występować jako „ABC Polska sp. z o.o.”, „ABC Poland” i po prostu „ABC”.

System wykrywania duplikatów powinien punktować zgodność kilku danych:

• NIP, KRS, REGON lub zagraniczny numer rejestrowy;
• domena internetowa;
• numer telefonu;
• pełny adres;
• współrzędne;
• znormalizowana nazwa;
• nazwy aliasowe;
• powiązanie z tą samą centralą.

Identyczny NIP powinien blokować utworzenie drugiego rekordu, o ile nie zachodzi wyjątkowa sytuacja migracyjna. Sama zgodność nazwy może jedynie uruchomić ostrzeżenie. Łączenie rekordów wyłącznie na podstawie podobieństwa tekstowego jest ryzykowne, zwłaszcza w branżach pełnych powtarzalnych nazw, takich jak budownictwo, transport, księgowość czy mechanika samochodowa.

Adresy URL również nie mogą zależeć wyłącznie od aktualnej nazwy. Rozsądny schemat to połączenie czytelnego sluga z trwałym identyfikatorem, np.:

/pl/firma/centrum-logistyki-48217

Po zmianie nazwy można zmienić slug i pozostawić identyfikator. Stary adres powinien zwracać przekierowanie 301, a nie błąd 404. W przeciwnym razie katalog traci wejścia z wyszukiwarki, zakładki użytkowników i linki prowadzące z innych stron.

Dla wersji językowych trzeba wybrać jeden spójny model:

• osobne katalogi, np. /pl/, /en/, /de/;
• albo osobne domeny i subdomeny, gdy rynki są faktycznie zarządzane niezależnie.

W większości katalogów branżowych katalogi językowe są prostsze i tańsze w utrzymaniu. Osobne domeny wymagają większego nakładu na pozycjonowanie, analitykę, przekierowania i zarządzanie reputacją każdej witryny.

Zaplanuj publikację, moderację i późniejsze aktualizacje

Najlepszy model danych nie pomoże, jeżeli redaktorzy i właściciele firm będą wpisywać nazwy według własnego uznania. Potrzebny jest proces zatwierdzania zmian, szczególnie gdy katalog umożliwia samodzielną edycję wizytówek.

Nowa albo zmieniona nazwa powinna przechodzić przez przynajmniej jeden z trzech trybów:

• publikacja automatyczna dla zweryfikowanego właściciela;
• moderacja przed publikacją;
• publikacja warunkowa z oznaczeniem rekordu do późniejszej kontroli.

W przypadku nazw rejestrowych warto sprawdzać dane w CEIDG, KRS lub właściwym rejestrze zagranicznym. Nazwy handlowe można potwierdzać na oficjalnej stronie przedsiębiorstwa, w stopce wiadomości e-mail, dokumentach firmowych albo podczas weryfikacji właściciela domeny. Nie każda zmiana musi być analizowana ręcznie, ale system powinien rejestrować kto, kiedy i z jakiej wartości zmienił nazwę.

Historia zmian jest potrzebna z kilku powodów. Pozwala:

• przywrócić poprawny zapis po błędnej edycji;
• rozpoznać firmę po dawnej nazwie;
• utrzymać działanie starych adresów URL;
• rozstrzygnąć spór między redakcją a właścicielem wpisu;
• ocenić, czy masowa zmiana nie została wykonana przez uszkodzoną integrację.

Praktyczny panel moderacyjny powinien pokazywać obok siebie wartość starą i nową, język, osobę zgłaszającą, źródło oraz inne rekordy o podobnej nazwie. Sam przycisk „zatwierdź” bez kontekstu prowadzi do szybkich, ale przypadkowych decyzji.

Duże znaczenie ma też import danych. Pliki CSV od partnerów zwykle zawierają jedną kolumnę z nazwą, niejednolity zapis języka i różne formaty numerów rejestrowych. Przed importem trzeba wykonać etap pośredni:

1. zmapować kolumny źródłowe;
2. wykryć język i alfabet;
3. oczyścić odstępy oraz niewidoczne znaki;
4. oddzielić formę prawną od nazwy tylko wtedy, gdy jest to potrzebne do wyszukiwania;
5. porównać rekordy po identyfikatorach;
6. skierować przypadki niejednoznaczne do ręcznej kontroli;
7. dopiero potem opublikować dane.

Nie należy automatycznie usuwać oznaczeń „sp. z o.o.”, „S.A.”, „GmbH”, „s.r.o.” czy „Ltd” z nazwy oficjalnej. Można przygotować dodatkowy wariant wyszukiwawczy bez formy prawnej, ale rekord źródłowy powinien zachować pełne brzmienie. Forma prawna pomaga odróżnić podmioty i ma znaczenie przy prezentowaniu danych rejestrowych.

Przy skali do około 10–20 tys. firm wyszukiwanie oparte na relacyjnej bazie danych i poprawnie przygotowanych indeksach zwykle wystarcza. Przy setkach tysięcy rekordów, wielu aliasach i obsłudze literówek warto rozważyć osobny silnik, np. OpenSearch, Elasticsearch albo Meilisearch. To jednak dodatkowa warstwa do utrzymania. Indeks może być przez kilka sekund lub minut niespójny z bazą, a źle skonfigurowana analiza językowa zacznie łączyć wyrazy, których nie powinna.

Koszt wdrożenia zależy bardziej od jakości danych i procesu moderacji niż od liczby języków. Dodanie kolejnego języka do dobrze zaprojektowanego systemu jest stosunkowo proste. Porządkowanie kilku tysięcy istniejących rekordów, w których nazwy, tłumaczenia i aliasy wymieszano w jednym polu, potrafi zająć wiele tygodni. Najwięcej czasu pochłaniają przypadki niejednoznaczne, których nie da się bezpiecznie rozstrzygnąć automatem.

FAQ

Czy każda firma musi mieć nazwę we wszystkich językach katalogu?
Nie. Trzeba jednak ustalić stałą regułę zastępowania brakującej wersji, np. język użytkownika, następnie język domyślny firmy, a na końcu nazwa rejestrowa.

Czy nazwy firm należy tłumaczyć automatycznie?
Nie jako nazwy oficjalne. Automatyczne tłumaczenie można wykorzystać do przygotowania roboczej propozycji lub opisu działalności, ale nazwa publikowana powinna pochodzić od firmy albo zostać zatwierdzona przez redakcję.

Czy dla każdego języka potrzebny jest osobny adres URL?
Tak, gdy strona zawiera lokalizowaną treść i ma być indeksowana w wyszukiwarkach. Adres powinien zawierać kod języka, natomiast rekord firmy musi zachować jeden trwały identyfikator.

Jak zapobiec dodawaniu tej samej firmy kilka razy?
Najpierw porównuj identyfikatory rejestrowe, domenę, telefon i adres. Podobieństwo nazw traktuj jako sygnał ostrzegawczy, a nie automatyczny dowód duplikatu.

Czy stara nazwa powinna zostać usunięta po rebrandingu?
Nie. Powinna trafić do historii lub aliasów, aby firma nadal była znajdowana, a stare linki i zapytania użytkowników nie prowadziły donikąd.

Od czego zacząć przebudowę istniejącego katalogu?
Najpierw usuń najgroźniejszy błąd: wykorzystywanie nazwy firmy jako identyfikatora rekordu. Nadaj każdej firmie trwałe ID, oddziel nazwy językowe do osobnej tabeli i dopiero później przebudowuj wyszukiwarkę, adresy URL oraz panel tłumaczeń. Bez tej kolejności każda korekta nazwy będzie nadal powodować duplikaty i zerwane powiązania.

Więcej informacji na: poadresie.pl