Prevodi
Problem kodiranja za prenos po posodobitvi 4.9.2
Prosimo, pošljite več podrobnosti o tem vprašanju. Ne vpliva stare prevode, ali le novo? Kateri prevod ponudniki uporabljate? Prosimo, navedite URL strani, kjer bomo lahko videli.
Lahko ga opazujejo na naši serwer? Če je odgovor da, kje?
Nazadnje urejal vBET; 07-05-18 pri 22:25.
Hvala za informacije. Bomo poskušali ponoviti na naši strani in odpraviti težavo. Če smo imeli težave z napako razmnoževanje bom poslal nekaj vprašanj (nisem dobil URL strani, kjer sem lahko ogledate na vprašanje - to bi bilo zelo userfull, ker sem lahko uporabite natančne besedilo, ki ga imajo težave z).
Pravkar sem naredil nekaj testov in na naši strani je videti v REDU. Prav tako sem v primerjavi kodo iz 4.9.2 in 4.9.1 javnost in ni nobene spremembe v prevodu kodo (smo spremenili konfiguracijo - nove jezikovne pare; in nekaj malo stvari, ki v izdelek datoteke). Bom PM vas, da poskusite ponoviti na vaši strani.
UPDATE: vidim, vprašanje je zdaj na naši strani. To je le približno nekatera besedila ne cele posodobitve. Zdi se, da je le približno temo. Mi bo poskrbel za to, in poslali vam informacije
UPDATE 2: naredil sem nekaj testov in zdi se, da je vprašanje, če je prevedeni obliki ruščina-ukrajinščina (ni težave s prevodom iz angleščine). Najbolj verjetno vBET je pošiljanje podatkov v napačno kodiranje, in da je razlog, zakaj so rezultati narobe. Sem preveril tudi pri 4.9.1 in isto vprašanje se zgodi. Ste prepričani, da na vaši strani za 4.9.1 je OK? To je pomembno, ker se moram priznati pa je težava z našo kodo sprememb ali nekaj se je spremenilo na Yandex strani.
Nazadnje urejal vBET; 08-05-18 pri 16:58.
Drugo posodobitev - po preizkusov ni nič narobe s Yandex prevode. Če pogledamo na razlike med vBET 4.9.1 in 4.9.2 verjetno vprašanje, ki je s Apertium prevajalec, ker v 4.9.2 smo dodali nov jezik par iz ru uk. Napisal si, da uporabljate samo, Yandex. Prosimo, potrdite, da je ta podatek je pravilen. Ne moremo ponoviti težavo, na Yandex prevajalec in zdaj se trudimo, da to storite na Apertium.
Update: Appertium tudi zdi, ne sme biti vprašanje. Lahko vas prosimo, da nas kontaktirate za PM, da bi dobili bolj podrobne informacije?
Update 2: ne moremo ponoviti težavo, na naše testiranje okolja, ampak tukaj je predstavljen vsak čas. Morda vB različica zadevah tukaj. Prosimo, kontaktirajte nas za PM.
Nazadnje urejal vBET; 09-05-18 pri 10:42.
V tem trenutku smo odkrili vzrok za težavo. Ko Apertium je uporabljeno z UTF-8 baze podatkov kodiranje potem pa bomo poslali poizvedbo v različne oblike zapisa in dobil tisti, \u odgovorov. Ko je zbirka podatkov v različne nastavitve, potem ni nobene težave s tem. Bomo posodobiti naše koda za delo s to primerno in rešitev bo objavljena tukaj.
Zdi se, da smo našli rešitev za vprašanje. Želimo, da ga test, ustrezno tudi ni UTF-8 baze podatkov, da bi se izognili vprašanja z različnih kodiranja. Rešitev, ki bodo vključeni v naslednjo izdajo. Do takrat lahko ostaneš z vBET4.9.1 ali pa uporabite vBET4.9.2 z Apertium onemogočen, ali uporabite vBET4.9.2 z invalidi Apertium samo za ukrajinski (treba spreminjati konfiguracijske datoteke).
Prosimo, upoštevajte, da že zlomljena prevodi ne bo popravljen samodejno. Tiste, ki jih je treba spremeniti ročno, z uporabo ročnega prevajanja podporo, ali odstranjen iz baze podatkov.
Nazadnje urejal vBET; 09-05-18 pri 16:41.
Med testi smo ugotovili, da se za ne UTF-8 podatkovnih baz Apertium ne bo posodobitve na vseh iz ruščine v angleščino, samo vrne besedilo z nekaj spremembami. To je naša krivda - smo tam poslati besedilo, v napačni obliki. To bo treba popraviti takoj.
Nazadnje urejal vBET; 10-05-18 pri 09:42.
Že imamo rešitev za to težavo. To bodo vključeni v naslednjo izdajo.
Odgovori s citatom
