Translations
Problem encoding transfer after the update 4.9.2
Please send more details about this issue. Does it affect old translations or only new one? Which translation providers do you use? Please give URL to your page where we can see it.
Can you observe it on our serwer? If yes, where?
Last edited by vBET; 07-05-18 at 22:25.
Thanks for information. We will try to reproduce it on our side and fix the issue. If we will have problems with bug reproduction I will send you some more questions (I didn't get URL to page where I can see the issue - it would be very userfull, because I could use exact text you have issues with).
I just made some tests and on our side it looks OK. I also compared code from 4.9.2 and 4.9.1 releases and there is no any change in translation code (we changed configuration - new language pairs; and some little things in product file). I will PM you to try to reproduce on your side.
UPDATE: I see the issue now on our side. It is only about some texts not whole translation. It seems it is only about topic. We will handle this and send you information
UPDATE 2: I made some tests and it seems that the issue is when it is translated form Russian to Ukrainian (there is no issue with translation from English). Most probably vBET is sending data in wrong encoding and that is why results are wrong. I checked it also in 4.9.1 and same issue happens. Are you sure that on your side for 4.9.1 it is OK? It is important, because I need to recognize does the issue is with our code changes or something was changed on Yandex side.
Last edited by vBET; 08-05-18 at 16:58.
Another update - according to your tests there is nothing wrong with Yandex translations. Looking on differences between vBET 4.9.1 and 4.9.2 most probably the issue is with Apertium translator, because in 4.9.2 we added new language pair from ru to uk. You wrote that you are using only Yandex. Please confirm is this information is correct. We are not able to reproduce the issue on Yandex translator and now we are trying to do it on Apertium.
Update: Appertium also seems not to be the issue. Can you please contact us by PM to get more detailed information?
Update 2: we are not able to reproduce the issue on our testing environment, but here it is reproduced every time. Perhaps vB version matters here. Please contact us by PM.
Last edited by vBET; 09-05-18 at 10:42.
At this moment we discovered cause of the issue. When Apertium is used with UTF-8 database encoding then we send query in different format and got those \u responses. When database is in different setting, then there is no issue with that. We will update our code to handle this appropriately and solution will be published here.
It seems we found solution for the issue. We want to test it appropriately also on not UTF-8 database, to avoid issues with different encodings. Solution will be included in next release. Until then you can stay with vBET4.9.1 or use vBET4.9.2 with Apertium disabled, or use vBET4.9.2 with disabled Apertium only for Ukrainian (need to change configuration in files).
Please note that already broken translations will not be repaired automatically. Those have to be changed manually, using manual translation support, or removed from database.
Last edited by vBET; 09-05-18 at 16:41.
During tests we discovered that for non UTF-8 databases Apertium doesn’t make translation at all from Russian to Ukrainian, just returns text with few changes. This is our fault - we send there text in wrong format. This will be corrected soon.
Last edited by vBET; 10-05-18 at 09:42.
We already have solution for this issue. It will be included in next release.
Reply With Quote
