Переводы
Проблема кодировки перевода после обновления 4.9.2
Пожалуйста, пришлите более подробную информацию об этой проблеме. Влияет ли это на старые переводы или только новый? Какие провайдеры переводов вы пользуетесь? Пожалуйста, дайте ссылку на Вашу страницу, где мы видим его.
Вы можете наблюдать его на нашем серуэр? Если да, то где?
Последний раз редактировалось vBET; 07-05-18 в 22:25.
Спасибо за информацию. Мы будем стараться, чтобы воспроизвести его на нашу сторону и устранить проблему. Если у нас будут проблемы с размножением ошибок я вышлю вам еще несколько вопросов (я не вам URL на страницу, где я вижу проблемы - это было бы очень userfull, потому что я мог использовать точный текст у вас есть проблемы с).
Я просто сделал несколько тестов и с нашей стороны это выглядит нормально. Я также сравнил код с 4.9.1 и 4.9.2 релизы и нет каких-либо изменений в код перевода (мы изменили конфигурацию - новых языковых пар; и кое-что в файл изделия). Я личку вам, чтобы попытаться воспроизвести на вашей стороне.
Обновление: я вижу сейчас на нашей стороне. Речь идет только о некоторых текстов не весь перевод. Кажется, речь идет только о теме. Мы справимся с этим и отправить вам информацию
Обновление 2: я сделал несколько тестов, и кажется, что вопрос, когда это перевод с русского на украинский (нет проблем с переводом с английского). Скорее всего vbet является отправка данных в неправильной кодировке и поэтому результаты неверные. Я проверил это и в 4.9.1 И же проблема происходит. Вы уверены, что на вашей стороне 4.9.1 это нормально? Это важно, потому что я должен признать, не проблема с нашими изменениями кода или что-то изменилось на стороне Яндекса.
Последний раз редактировалось vBET; 08-05-18 в 16:58.
Еще одно обновление - по данным тестов нет ничего плохого с переводами Яндекс. Глядя на различия между vbet 4.9.1 и 4.9.2 скорее всего проблема связана с Apertium переводчик, потому что в 4.9.2 мы добавили новые языковые пары из RU в Великобритании. Вы писали, что вы пользуетесь только Яндекс. Пожалуйста, подтвердите эту информацию правильно. Мы не смогли воспроизвести проблему на переводчик Яндекс и теперь мы пытаемся делать это на Apertium.
Обновление: Appertium тоже вроде не проблема. Пожалуйста, вы можете связаться с нами по личке, чтобы получить более подробную информацию?
Обновление 2: мы не смогли воспроизвести проблему на нашей тестовой среде, но здесь она воспроизводится каждый раз. Возможно, тут имеет значение версия глаг. Пожалуйста, свяжитесь с нами по ПМ.
Последний раз редактировалось vBET; 09-05-18 в 10:42.
В этот момент мы обнаружили причину проблемы. Когда Apertium используется с utf-8 Кодировка БД, то мы отправим запрос в другой формат и у тех \ответы у. Когда база данных находится в другой обстановке, то нет никакой проблемы с этим. Мы будем обновлять наш код, чтобы обработать это правильно и решения будут опубликованы здесь.
Кажется, мы нашли решение проблемы. Мы хотим, чтобы проверить его должным образом и на не utf-8 базы данных, чтобы избежать проблем с разными кодировками. Решение будет включено в следующий релиз. До тех пор вы можете остаться с vBET4.9.1 или использовать vBET4.9.2 с Apertium отключить, или использовать vBET4.9.2 с Apertium отключаются только на украинском (надо менять настройки в файлах).
Обратите внимание, что уже сломанные переводы не будут автоматически восстановлены. Те должны быть изменены вручную, используя ручные поддержки перевода, или удалены из базы данных.
Последний раз редактировалось vBET; 09-05-18 в 16:41.
Во время тестов мы обнаружили, что для не utf-8 базы данных Apertium не делают перевода с русского на украинский, просто возвращает текст с небольшими изменениями. Это наша вина - мы отправляем текст в неправильном формате. Это будет скоро исправлено.
Последний раз редактировалось vBET; 10-05-18 в 09:42.
У нас уже есть решение для этой проблемы. Он будет включен в следующий релиз.
Ответить с цитированием
