Ek verstaan jou beskrywing en jou punt. Nou het ons om uit te vind hoe dit veronderstel is om te tegnies te werk.
Een kwessie wat ek hier sien, is hoe ons sal erken dat ons reeds beskikbaar perke ná dié waar bereik moet word voordat is.
Ons het elke keer kan net vra voorkeurverskaffer en dan gaan jy na die volgende een. Dit sal koste prestasie - want vir elke versoek aan bladsy wat vertaling vereis, sal ons onsuksesvol oproep gemaak na voorkeurverskaffer, dan na die volgende een (sodat dit kan word om verskeie onsuksesvolle oproepe wanneer vBET meer APIs ondersteun).
Ander oplossing sou wees om inligting wat voorkeur-verskaffer nie beskikbaar is nie te slaan en gaan direk na die volgende een. Dit sou baie vinniger, omdat die kontrolering van lokale veranderlike is baie vinniger as om te wag vir die reaksie van eksterne bediener. Hierdie keer het ons 'n ander saak - ons weet nie wanneer voorkeurverskaffer is beskikbaar. Ons kan natuurlik 'n paar geskeduleerde taak wat vra vir' n eenvoudige (kort) vertaling byvoorbeeld een keer per uur / dag om dit te sien. So in hierdie strategie het ons om te besluit hoe gereeld by verstek sodanige taak veronderstel is om te werk. Natuurlik sou ons kyk dit slegs wanneer 'n verskaffer is gemerk as nie beskikbaar is nie.
Ook as ons merk verskaffers nie beskikbaar nie - wat om te doen wanneer ons weet dat die verskaffers nie beskikbaar is - voeg 'n bietjie inligting vir die eindgebruiker of net vertaal wat in die kas en die res as die oorspronklike is, sonder enige verdere inligting oor die tydelike gebrek aan vertaling verskaffers .
Maak nie saak watter manier waarop dit gedoen sal word, sal Google beskou word as een API (v1 of V2 afhangende van configuration) - daar is geen sin om dit te verdeel nie, omdat Google v1 sal binnekort gesluit word.
Nog 'n ding is om verskaffers tou te stel vir elke taalpaar afsonderlik. Op die oomblik is vBET kan reeds die verskaffer van die vertaling instel vir elke taalpaar. Ek dink dat ons dit kan verander van 'n waarde te kommas geskei waardes (CSV). Op hierdie manier sal ons weet vir elke taalpaar wat bied ondersteuning vir hierdie vertaling en wat is 'n orde voorkeure (net orde op CSV lys).
LET WEL: Dit sal 'n prestasie impak elk geval. In plaas van die skep van een voorwerp vir vertaling sal ons die skikking van sodanige voorwerpe en addisionele wikkel voorwerp (deursigtig vir ander dele van die kode en minder foute geneig om dit) te skep. Natuurlik sal ons nie voorwerpe skep vir verskaffers van ons weet nie beskikbaar is nie op hierdie oomblik.
Oplossing vir hierdie sou wees om weer instel vir beter prestasie en verwyder verskaffers queue - net soos dit nou is - 'n verskaffer per taalpaar.
Dit moet nie duur wees vir die prestasie, maar nog 'n paar ekstra logika en geheue verbruik.
Let asseblief vertel wat die oplossing is verkies.