Jeśli nie używam Polylang Pro, slugi nie mogą być ponownie używane. Co to oznacza?

W WordPress slugi kategorii i tagów muszą być unikalne w bazie danych w całej witrynie — nie per język. Nie można więc zachować dokładnie tego samego slugu dla terminu w języku angielskim i jego tłumaczenia w języku hiszpańskim, gdy oba by kolidowały.

Przykład: masz tag „banana" w języku angielskim, a tłumaczenie to również „banana" w języku hiszpańskim. Slug w języku angielskim to banana. WordPress nie zapisze drugiego terminu ze slugiem banana, więc Polylang przypisze coś w rodzaju banana-2 dla tagu w języku hiszpańskim.

Polylang Pro obchodzi to ograniczenie za pomocą funkcji, która efektywnie „współdzieli" slugi: zachowuje się tak, jakby slug miał wartość banana-2, a następnie nadpisuje SQL tuż przed zapisaniem wiersza, tak że baza danych ostatecznie zawiera banana. To swego rodzaju obejście, ale jest to ugruntowana metoda uzyskiwania identycznych slugów tam, gdzie WordPress normalnie by tego zabraniał.

Zatem:

• Jeśli potrzebujesz tego samego slugu we wszystkich językach (czyste adresy URL, oczekiwania SEO, spójność), potrzebujesz Polylang Pro (lub innego podejścia rozwiązującego to samo ograniczenie).
• Jeśli akceptujesz sporadyczne sufiksy takie jak -2, wystarczy wersja bezpłatna.

Jak często w praktyce pojawia się -2? Zazwyczaj tylko wtedy, gdy przetłumaczona nazwa dałaby ten sam slug co oryginał — np. kognatyw takich jak „banana" → „banana". Jeśli po angielsku jest „apple", a po hiszpańsku „manzana", slugi to apple i manzana, więc nie ma żadnej kolizji.

Praktyczne podejście: zacznij od Polylang bezpłatnego, sprawdź, ile terminów kończy się na -2. Jeśli później przejdziesz na Pro, możesz ręcznie edytować te kilka slugów — zazwyczaj jest ich tylko garść.