Probleem codering overdracht na de update 4.9.2

[Vetall]

Hi!

Na het upgraden van 4.9.2 vertaling van de oekraïense taal:


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

: Verward:

[vBET]

Stuur voor meer informatie over dit probleem. Heeft het invloed oude vertalingen of alleen de nieuwe? Die vertaling providers gebruik je? Geef dan de URL van uw pagina, waar we kunnen zien.
Kunt u zien op onze serwer? Zo ja, waar?

[Vetall]

1. Gebruik Yandex Vertaling API met vBET
2. Dit merkte codering (\u0414\u0432) alleen voor nieuwe vertalingen.
3. Rolde vBET te 4.9.1 - er is geen probleem.

[vBET]

Dank voor de informatie. We zullen proberen het te reproduceren, aan onze kant en het probleem oplossen. Als we problemen hebben met een bug reproductie, stuur ik u wat meer vragen (ik heb niet de URL naar de pagina waar ik kan zien dat de kwestie - het zou heel userfull, want ik kon gebruik maken van exacte tekst die u hebt problemen met).

[vBET]

Ik heb net een aantal tests en aan onze kant ziet het er OK. Ik ook vergeleken met de code van 4.9.2 en 4.9.1 versies en er is geen verandering in de vertaling code (we gewijzigde configuratie - nieuwe talencombinaties; en sommige kleine dingen in het product-bestand). Ik PM je om het probleem te reproduceren op uw zijde.

UPDATE: ik zie het probleem nu aan onze kant. Het is slechts een deel van de teksten niet geheel vertaling. Het lijkt erop dat het alleen over het onderwerp. Wij verwerken dit en u informatie toe te zenden :)

UPDATE 2: ik heb een aantal tests en het lijkt erop dat het probleem is wanneer het wordt vertaald vorm russisch-oekraïense (er is geen probleem met de vertaling uit het engels). Waarschijnlijk vBET is het verzenden van gegevens in verkeerde codering en dat is de reden waarom de resultaten zijn verkeerd. Ik controleerde het ook in 4.9.1 en hetzelfde probleem gebeurt. Weet u zeker dat aan uw kant voor 4.9.1 het is OK? Het is belangrijk, want ik moet erkennen, treedt het probleem is met onze code wijzigt of er iets is gewijzigd op Yandex kant.

[vBET]

Een andere update - volgens de tests er is niets mis met Yandex vertalingen. Zoeken op verschillen tussen vBET 4.9.1 en 4.9.2 meest waarschijnlijk is het probleem met Apertium vertaler, omdat in 4.9.2 we toegevoegd een nieuwe taal paar van ru naar het verenigd koninkrijk. U schreef dat u alleen Yandex. Gelieve te bevestigen is deze informatie correct is. We zijn niet in staat het probleem te reproduceren op Yandex vertaler en we proberen nu om het te doen op Apertium.

Update: Appertium lijkt ook niet het probleem. Kunt u alstublieft contact met ons op via PM voor meer gedetailleerde informatie?

Update 2: we zijn niet in staat het probleem te reproduceren op onze testomgeving, maar hier is reproduceerbaar. Misschien vB versie van zaken hier. Neem dan contact met ons op via PM.

[vBET]

Op dit moment hebben wij ontdekt oorzaak van het probleem. Wanneer Apertium wordt gebruikt met UTF-8-database codering dan sturen wij query in een andere indeling en kreeg die \u antwoorden. Wanneer de database is in een andere instelling, dan is er geen probleem met dat. We werken onze code om dit te verwerken en adequate oplossing worden hier gepubliceerd.

[vBET]

Het lijkt erop dat we gevonden oplossing voor het probleem. We willen testen het op de juiste wijze ook op geen UTF-8-database, om problemen te voorkomen met verschillende coderingen. De oplossing zal worden opgenomen in de volgende release. Tot dan kun je verblijf met vBET4.9.1 of gebruiken vBET4.9.2 met Apertium uitgeschakeld, of gebruik vBET4.9.2 voor gasten met een handicap Apertium alleen voor oekraïense (moet het wijzigen van configuratie-bestanden).

Houd er rekening mee dat al gebroken vertalingen zullen niet worden hersteld automatisch. Die moet handmatig worden gewijzigd, met behulp van handmatige vertaling ondersteuning, of verwijderd uit de database.

[vBET]

Tijdens tests bleek dat voor niet UTF-8 databases Apertium niet vertaling uit het russisch in het engels, net terug van een tekst met een paar veranderingen. Dit is onze fout - verzenden we er tekst in het verkeerde formaat. Dit zal worden gecorrigeerd snel.

[vBET]

Wij hebben al een oplossing voor dit probleem. Zij zullen worden opgenomen in een volgende release.