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

[Vetall]

Здравейте!

След актуализиране на 4.9.2 превод на Украински език, става така:


\u0414\u0432\u0438\u0433\u0443\u043d\u0438

: Объркана:

[vBET]

Моля изпратете повече информация за този проблем. Засяга стари преводи или само нови един? Кои преводи доставчици да използвате? Моля, дайте URL на страницата си където можем да я видим.
Може да го спазват на нашия serwer? Ако да, къде?

[Vetall]

1. Използвам Yandex API with vBET
2. Забелязах такава кодиране (\u0414\u0432) само за нови преводи.
3. Откатил vBET до 4.9.1 - в нея няма такъв проблем.

[vBET]

Благодаря за информацията. Ние ще се опитаме да го възпроизвежда на наша страна и прикрепвам определителен член изход. Ако ще имаме проблеми с възпроизвеждане на бъг ще ви изпратим още въпроси (аз не получи URL към страница, където мога да видя въпроса - би било много userfull, защото мога да използвам точния текст, имате проблеми с).

[vBET]

Току-що направи някои тестове и от нашата страна изглежда ОК. Аз също сравнявам код от 4.9.2 и 4.9.1 издания и няма някаква промяна в превод код (променихме конфигурация - нови езикови двойки; и някои малки неща в продукта файл). Аз ще ч. можете да се опитате да възпроизведете на ваша страна.

UPDATE: аз виждам проблема сега на наша страна. Това е само за някои текстове не цял превод. Изглежда, че това е само за тема. Ние ще се справим с това и ви изпрати информация :)

UPDATE 2: Аз също направи някои тестове и изглежда, че въпросът е, когато то е преведено образуват руски на украински (там е никакъв изход с превод от английски). Най-вероятно vBET изпраща данни в неправилно кодиране и това е защо резултатите са неверни. Проверих го също в 4.9.1 и същия проблем се случва. Сигурни ли сте, че на ваша страна за 4.9.1 е ОК? Важно е, защото ми трябва да познавам дали проблемът е с нашите код промени или нещо е променено от Yandex страна.

[vBET]

Друга актуализация - според си тестове там е нищо крив с Yandex преводи. Търси разликите между vBET 4.9.1 and 4.9.2 най-вероятно въпросът е с Апертиум преводач, защото в 4.9.2 добавихме нови езикова двойка от ru до Великобритания. Ти си написал че използвате само Yandex. Моля да потвърдите тази информация е правилна. Ние не сме в състояние да възпроизведете проблема на Yandex преводач и сега се опитваме да го направи на Apertium.

Update: Appertium също не изглежда да бъде проблем. Може да ви моля свържете се с нас от PM да получите по-подробна информация?

Update 2: не сме в състояние да възпроизведете проблема на нашата среда за изпитания, но тук тя се възпроизвежда всеки път. Може би версия на vB въпроси тук. Свържете се с нас от PM.

[vBET]

В този момент сме открили причината за проблема. Когато Apertium е използван с UTF-8 database кодиране тогава ние изпрати заявка в различен формат и имам тези/u отговори. Когато базата данни е в различна обстановка, тогава там е не проблем с това. Ние ще се актуализира нашия код, за да се справят с това по подходящ начин и решение ще бъде публикувана тук.

[vBET]

Изглежда, че сме намерили решение за издаване. Ние искаме да го тествате подходящо също на не UTF-8 база данни, за да се избегнат проблеми с различни кодировки. Решение ще бъде включена в следващата версия. До тогава можете да останете с vBET4.9.1 или използвайте vBET4.9.2 с Апертиум инвалиди, или употреба vBET4.9.2 с увреждания Апертиум само за украински (трябва да променя конфигурацията файлове).

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

[vBET]

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

[vBET]

Вече имаме решение за този проблем. Той ще бъде включен в следващата версия.