Автоматично откриване на езика в chatbot: предпочитания, резервни варианти и избор на потребителя

Многоезичният уебсайт Chatbot не трябва да изпраща посетителите на грешния език още с първия отговор. Но автоматичното откриване на езика в Chatbot означава много повече от простото приемане на първата стойност от браузъра. Настройките на браузъра могат да бъдат остарели, дадено устройство може да се споделя, а даден човек може да предпочита да чете техническо съдържание на английски, въпреки че операционната му система използва български.

Затова едно стабилно решение третира автоматичното откриване само като начален сигнал. Изричният избор на потребителя има приоритет, наличността на интерфейса, базата от знания и процеса на прехвърляне поставят граници, а видим резервен вариант (fallback) предотвратява възможността привидно подходящ език да доведе до непълни или измислени отговори.

Защо езикът на браузъра е само подсказка

Браузърите често изпращат HTTP заглавката Accept-Language. Тя съдържа езикови диапазони и може чрез така наречените стойности за качество да изрази подредба, например de-AT,de;q=0.9,en;q=0.7. Стандартът RFC 9110 изрично описва тези предпочитания като помощ за избор на представяне, а не като сигурно твърдение за даденото лице.

В браузъра navigator.languages предоставя подреден списък с предпочитани BCP-47 езикови тагове. Според MDN браузърите обаче могат да разкриват по-малко предпочитания от съображения за поверителност. Освен това, при определени обстоятелства браузърът допълва по-общи варианти: от de-AT за съпоставяне може допълнително да стане релевантно и de .

Практическото следствие за чатботовете е: Accept-Language и navigator.languages са добри кандидати за първото предложение. Те обаче не трябва да заместват нито местоположението, нито гражданството. IP адресът не разкрива надеждно езиково желание. Нито домейнът, нито езикът на страницата са достатъчни сами по себе си, ако посетителят съзнателно е преминал към друга езикова версия.

Ясната верига от приоритети предотвратява изненади

Изборът трябва да бъде детерминиран. Доказала се е подредба, която ясно претегля всеки източник:

1. Изричен избор в текущата сесия: Ако потребителят кликне върху френски, следващият отговор на Chatbot трябва да използва френски.
2. Запазено, все още валидно предпочитание: Предишен избор може да важи отново при последващо посещение, при условие че съхранението е прозрачно и технически допустимо.
3. Език на текущата страница: Chatbot не трябва без причина да се отклонява от съзнателно отворената езикова версия.
4. Предпочитания на браузъра: Списъкът се съпоставя с действително поддържаните от Chatbot локали.
5. Документиран стандарт: Ако нищо не съвпада, се следва съзнателно избран основен език вместо случаен резултат.

Тази верига разделя откриването от решението. Тя може да се логва и тества: source=user, source=stored, source=page, source=browser или source=default. За анализите обикновено са достатъчни източникът и избраният локал. Пълният езиков списък на браузъра не трябва да се съхранява ненужно, тъй като RFC 9110 посочва възможните рискове за поверителността и дигиталния отпечатък (fingerprinting) от подробните езикови предпочитания.

Нормализиране на BCP-47 таговете без загуба на значение

Езиковите тагове не се състоят само от две букви. pt-BR и pt-PT споделят един език, но могат да се различават по тоналност, избор на думи, формати и правни термини. Пирамените системи също могат да бъдат от решаващо значение. Ето защо приложението трябва синтактично да нормализира входящите тагове и след това да ги провери спрямо изричен списък с поддържани локали.

От специфичния таг до сигурния резервен вариант

Разумното съпоставяне първо опитва точния вариант. Ако de-AT не е наличен, може да последва de . След това може да влезе в сила познат, редакционно проверен стандартен локал. Но простото изрязване на всички подтагове не винаги е сигурно. При езици с множество писмености или силно различаващи се варианти продуктът се нуждае от съзнателно дефинирано съответствие.

Резервният вариант трябва да се провери отделно за три нива: Преведен ли е потребителският интерфейс на чата? Има ли подходящи източници на знания? Може ли екипът за поддръжка да поемат този език? Локализираният бутон все още не е доказателство, че базата от знания има същото покритие. Как източниците се разделят по език, версия и достъп, показва статията за филтри за метаданни при RAG за AI чатботове.

Предлагане на автоматика със запазване видимостта на избора

Препоръката за интернационализация на W3C комбинира автоматичното езиково посредничество с лесно откриваеми връзки към алтернативни езикови версии. Ако потребителят сам промени езика, този избор трябва да замени предпочитанието на браузъра и по желание да се запази за следващите страници.

За един Chatbot това означава: активният език трябва да бъде видимо разположен в горната част на чата или в лесно достъпно меню. Промяната не трябва незабелязано да изпраща незавършено съобщение. Вместо това въведеният текст се запазва, ботът кратко обяснява езиковата промяна и продължава разговора по контролиран начин. Ако предишни съобщения са налични на друг език, системата трябва да запази тяхното значение за контекста, но да не превежда целия ход на разговора без запитване.

Добра формула е например: „Български беше преет от тази страница. Промяна на езика.“ При резервен вариант съобщението може да бъде по-конкретно: „За български няма проверена информация по тази тема. Мога да използвам английския източник или да ви прехвърля към екипа по поддръжка.“ Така потребителят разбира защо се променя езикът или дълбочината на отговора.

Разделяне на езика на страницата, езика на чата и локала на съдържанието

Три стойности често грешно се обединяват в едно поле:

• Език на страницата: основният език на HTML документа;
• Език на чата: езикът, на който се появяват интерфейсът и отговорите;
• Локал на съдържанието: вариантът, от който Chatbot има право да извлича потвърдена информация.

Тези стойности могат да бъдат еднакви, но не е задължително. Българскоговорящ потребител може да зададе въпрос на български в английска продуктова страница. Ботът може да отговори на български и все пак прозрачно да се позове на оригинален английски източник. Той обаче не трябва да твърди, че е използвана български източник, ако само отговорът е преведен.

За достъпността езикът на документа и съдържанието трябва да бъде правилно обозначен. Техниката на W3C H57 описва атрибута langв елемента html, така че екранните четци (screen readers) да могат да обработват подходящо произношението и синтаксиса. Ако отделен раздел промени езика, този регион също се нуждае от подходяща маркировка. Допълнителни проверки са събрани в контролния списък на WCAG за уебсайт чатботове.

Кешът и URL адресите трябва да зачитат избора на език

Всеки, който избира съдържание от страната на сървъра според Accept-Language , трябва да вземе предвид стратегията за кеширане. RFC 9110 обяснява, че Vary: Accept-Language сигнализира на кешовете, че заглавката е повлияла на представянето. Ако това разделение липсва, кешът може да достави българската версия на англоговорящ посетител.

За публично, индексируемо съдържание стабилните специфични за даден език URL адреси често са по-лесни за проверка и споделяне. Автоматичното откриване може тогава да води към подходящ URL адрес, без да крие различно съдържание под един и същ адрес. В самия чат локалът трябва да бъде част от състоянието на сесията и всяка заявка от страната на сървъра. Промяната на езика трябва съвместно да актуализира ключовете за кеша, филтрите за извличане и генерирането на отговори.

Форматираните стойности също принадлежат към този договор. Датата, числото, валутата и часовата зона не следват автоматически правилно от езика на текста. Ръководството локализиране на отговорите на чатбота показва как тези данни се третират отделно и последователно.

Резервните формати не трябва да прикриват пропуски в съдържанието

Най-рискованата грешка е тихата промяна на базата от знания. Ако за въпрос на български не съществува статия на български, ботът може да използва английски източник, при условие че продуктът позволява този път. Той обаче трябва да провери източника, актуалността и разрешенията точно както при директно съвпадение.

Сигурната матрица за резервни варианти съдържа най-малко: заявен локал, наличен UI локал, наличен съдържателен локал, допустим заместващ локал, режим на превод и цел за прехвърляне (handoff). Резултатът не винаги е отговор. При чувствителни или силно зависими от контекста теми „няма проверена информация на този език“ е по-добре от плавен, но непотвърден превод. Статията за резервни варианти при пропуски в знанията описва как сигурността и прехвърлянето взаимодействат.

Тестови случаи за езиковата логика

Малък, систематичен тестов набор открива повече грешки от единична проверка на браузъра. Той трябва да покрива най-малко следните случаи:

• de-AT се предлага, поддържа се само de;
• първото предпочитание на браузъра не е налично, второто е;
• изборът на потребителя противоречи на езика на страницата и браузъра;
• запазеното предпочитание сочи към премахнат междувременно локал;
• интерфейсът е наличен, но базата от знания или прехвърлянето – не;
• промяната на езика се случва по средата на разговор с неизпратен текст;
• кешът наистина доставя новия локал след промяната;
• екранният четец открива правилно езика на страницата и раздела;
• анализите отчитат източника на избор и резервния вариант, но без ненужно подробен списък с предпочитания.

За всяка комбинация екипите трябва да фиксират очаквания локал, източника на решението, видимата индикация и разрешения съдържателен периметър. В допълнение, всеки език се нуждае от специализирани извадки. Пълнотата и качеството на отговорите не могат да се съдят само по наличието на ред с превод.

Практически контролен списък за въвеждане

1. Инвентаризиране отделно на всички поддържани UI, съдържателни и handoff локали.
2. Документиране на ясна верига от приоритети за избора на потребителя, запазения избор, страницата, браузъра и стандарта.
3. Дефиниране на BCP-47 съпоставяне, включително регионални и свързани с писмеността изключения.
4. Оформяне на езиковата промяна видимо и без загуба на въведения текст.
5. Ограничаване на резервните варианти до покритието на източника, актуалността и разрешенията.
6. langПроверка на специфичните за езика URL адреси, каноничните елементи и поведението на кеша.
7. Съхраняване само на необходимите данни за анализи и определяне на периода за съхранение.
8. Тестване на настолни компютри, мобилни устройства, клавиатури и екранни четци с реалистични списъци с предпочитания.

Централното продуктово решение не гласи: „Кой език използва този посетител?“. То гласи: „Кой език беше поискан, кое съдържание е надеждно налично за него и как да обясним необходимия алтернативен път?“. Всеки, който отговори отделно на тези три въпроса, получава Chatbot, който автоматично става полезен от самото начало, но оставя контрола у потребителя.

Източници

• RFC 9110: Accept-Language, Vary и поверителност
• MDN: Navigator.languages
• W3C Internationalization: Насочване на потребители към преведени страници
• W3C WAI: Обозначаване на езика на документа с lang