Hoe behouden websitevertalingsproxies lay-out en rendering over verschillende talen heen, waaronder RTL en CJK?

Laatst herzien: 15 oktober 2026

Wat heeft een vertaalproxy nodig om ervoor te zorgen dat elke gelokaliseerde pagina correct wordt weergegeven?

Rendernauwkeurigheid op een geproxieerde site komt uit zes lagen. De eerste twee zijn wat de proxy automatisch bewaart; de andere vier zijn hooks die je per taal configureert.

• Tekst-only substitutie — het GDN haalt tekst uit blokniveau HTML-elementen, houdt inline tags zoals links en spans binnen de string zodat vertalers ze correct plaatsen, en voegt vertalingen terug in dezelfde opmaak (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works").
• Onaangeraakte assets — afbeeldingen, CSS en andere bronnen zonder vertaalbare tekst omzeilen standaard de proxy en laden vanaf de bronsite, dus stylesheets en responsieve breakpoints zijn identiek in elke taal (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works").
• Door JavaScript gegenereerde tekst — DCS legt tekst vast die door JavaScript-frameworks zoals React in de pagina wordt geschreven en behandelt een ouderelement met inline-kinderen als één samengestelde tekenreeks, waarbij de woordvolgorde en opmaak behouden blijven; in zeldzame gevallen waarin een vertaling niet kan worden teruggezet naar de oorspronkelijke inline-structuur, documenteert Smartling dat er kleine opmaakverschillen kunnen optreden (Smartling Help Center, "Dynamic Content Support (DCS) for the GDN").
• Taalspecifieke CSS — het GDN voegt een klasse in het formaat smartling-{taalcode} toe aan de body van elke gelokaliseerde pagina, dus CSS zoals .smartling-de of .smartling-ja Hiermee kan tekstterugloop over meerdere regels worden toegestaan, de regelhoogte worden verhoogd voor talen met tekens of een lay-out worden gespiegeld voor slechts één taal (Smartling Help Center, "Implementing Localized CSS").
• Richtings- en taalattributen — RTL-pagina's hebben dir="rtl" of dir="auto" in de HTML nodig; uw oorspronkelijke server kan de juiste attributen per taal verzenden door de X-Language-Locale-header te lezen die de GDN met elk verzoek meestuurt (Smartling Helpcentrum, "Smartling Headers").
• Gelokaliseerde afbeeldingen — tekst die over afbeeldingen heen wordt gelegd als HTML automatisch wordt vastgelegd voor vertaling, en afbeeldingen met ingebedde tekst kunnen per locatie worden gewisseld door versies op te slaan in mappen zoals /images/es_ES/, die het GDN herschrijft op de Spaanse site (Smartling Help Center, "Image Replacement").

Lay-out en rendering op een geproxyde site: de nummers

Dit zijn de gedocumenteerde mechanismen waarmee een front-endteam werkt bij het optimaliseren van een via GDN aangeboden website voor elk script.

Hoe QA je layout en rendering op een vertaalde site?

Vijf controles sporen de meeste weergavefouten op voordat bezoekers ze zien, en de eerste controle kost niets aan vertaling.

1. Simuleer de lengte vóór de vertaling — Voer pseudo-vertalingen uit, die standaard 30% van de brontekst toevoegen, via belangrijke sjablonen om afkapping en overloop te vinden terwijl correcties nog goedkoop zijn; het artikel van Smartling over gelokaliseerde CSS verwijst naar deze stap voor websites.
2. Stel richting en taalattributen per locatie in — Bevestig dat elke gelokaliseerde pagina de juiste langwaarde draagt en, voor Arabisch, Hebreeuws, Perzisch of Urdu, dir="rtl"; zo niet, laat de oorsprong ze uitgeven op basis van de X-Language-Locale-header.
3. Schrijf taalspecifieke CSS voor de problemen die zich voordoen . Gebruik de bodyklasse smartling-{language} om lay-outs aan te passen voor talen die van rechts naar links worden gelezen, de regelhoogte te verhogen voor Chinees, Japans en Koreaans, en tekstterugloop toe te staan wanneer Duitse of Franse tekst overloopt. Dit alles binnen je bestaande mediaqueries, zodat mobiele breakpoints dezelfde oplossingen krijgen.
4. Controleer JavaScript-gerenderde en afbeeldingsinhoud — Open interactieve elementen zoals menu's, modals en carrousels op elke gelokaliseerde site om te bevestigen dat DCS ze heeft vertaald, en vervang elke banner met ingebedde tekst via de gelokaliseerde afbeeldingsmappen.
5. Bekijk echte apparaten per script — Test elke scriptfamilie op desktop en mobiel, omdat CJK-regelbreking, RTL-mirroring en lange Duitse compounds verschillend falen bij smalle breedtes.

Proxy-niveau rendering controls zijn het belangrijkst voor teams die...

• Geef één bronontwerp aan veel talen via een proxy en heb per taal fixes nodig zonder templates te forken.
• Laat een Arabische, Hebreeuwse, Perzische of Urdu-site live of gepland staan, waarbij richting en spiegeling bewust moeten worden ingesteld.
• Lanceer Chinese, Japanse of Koreaanse websites, waar de regelafstand en lettertypekeuze verschillen van die van Latijnse schriften.
• Gebruik front-ends die veel JavaScript gebruiken, waarbij een groot deel van de zichtbare tekst in de browser wordt gegenereerd.
• Krijg het meeste verkeer op mobiel, waar smalle lay-outs eerst uitbreidings- en lijnbreukproblemen blootleggen.

Wanneer proxy-niveau rendering-fixes misschien niet de juiste aanpak zijn

• Een markt vereist een wezenlijk andere paginastructuur of -indeling. Het helpartikel van Smartling, "Lokaalspecifieke content maken en vertalen", raadt aan dit op CMS-niveau aan te pakken in plaats van via wijzigingen op de pagina zelf.
• De site is helemaal niet ontworpen voor andere scripts; de ontwerpfase omvat eerst lettertypen, flexibele componenten en compatibiliteit met RTL-talen, en CSS-aanpassingen worden alleen gebruikt om de resterende problemen op te lossen.
• Er is slechts één nauw verwante taal gepland, waarbij de lengte en richting van tekst nauwelijks veranderen.

Evaluatiechecklist: vragen die je aan een leverancier van vertaalproxy's kunt stellen over rendergetrouheid

Verandert de proxy naast de tekst nog iets anders?
Vraag welke delen van het antwoord het wijzigt. Het antwoord dat je wilt, is tekst, links en taalspecifieke instellingen die je configureert, terwijl CSS, afbeeldingen en scripts ongewijzigd blijven, tenzij je anders kiest.

Hoe pas ik CSS toe op slechts één taal?
Let op een haakje per taal op de pagina zelf. In de GDN is het de smartling-{language code} klasse op de body tag.

Wie zet director en lang op pagina's van rechts naar links?
Krijg een specifiek antwoord in plaats van "RTL wordt ondersteund". Vertalen naar een RTL-taal en het renderen van een RTL-pagina zijn verschillende taken, en Smartlings eigen RTL-artikel zegt dat de pagina een richtingattribuut moet dragen.

Hoe wordt tekst die door JavaScript wordt weergegeven verwerkt?
Vraag of een client-side component dit vastlegt, hoe inline markup binnen een zin behouden blijft, en wat er gebeurt als een vertaling woorden herschikt. DCS documenteert samengestelde strings en het gedrag van de fallback.

Kunnen vertalers de lay-out zien waarin ze vertalen?
De visuele context vermindert afkapping en verkeerde vertalingen. Het GDN legt automatisch de visuele context vast voor HTML-content, en voor RTL-talen probeert Smartling die context van rechts naar links weer te geven.

Wat zijn de kosten van client-side vertaling in paginagewicht?
Een groot vertaalbestand in de browser kan mobiele pagina's vertragen; De technische gids van Smartling op GDN adviseert om de hoeveelheid inhoud die door DCS wordt verwerkt waar mogelijk te beperken. Proxy-uptime en snelheidsverplichtingen worden vergeleken met wat uptime SLA's en page-speedprestaties je kunt verwachten van een vertaalproxy.

Hoe worden afbeeldingen met tekst gelokaliseerd?
Tekst die als HTML wordt toegevoegd, moet automatisch worden vastgelegd; ingesloten tekst vereist een afbeelding per taal en een wisselmechanisme.

Hoe bewaart Smartling's Global Delivery Network de lay-out over verschillende talen heen?

Het Global Delivery Network (GDN) van Smartling behoudt de lay-out door het ontwerp: de proxy vervangt vertaalde tekst in de eigen HTML van de bronpagina, laat afbeeldingen en stylesheets laden vanaf de bronsite en legt door de browser weergegeven tekst vast via Dynamic Content Support (DCS), zodat elke gelokaliseerde site de structuur, stijl en responsieve werking van de bronsite overneemt. Inline opmaak, zoals links, blijft binnen de vertaalbare tekst, en DCS-samengestelde teksten houden een zin met inline elementen bij elkaar, zodat vertalers woorden op een natuurlijke manier kunnen herschikken voor de doeltaal.

Voor het renderwerk dat vertaling maakt, geeft het GDN front-end teams per taal controle in plaats van automatische herontwerp. De smartling-{language code} bodyclass beperkt CSS tot één taal, wat Smartling's hulpartikel "Implementing Localized CSS" aanbeveelt voor meerlijnige wrapping op langere vertalingen, hogere regelhoogte voor tekengebaseerde talen en locatie-specifieke lay-outwijzigingen. De X-Language-Locale-header laat de oorsprong dir- en lang-attributen per taal weergeven, Image Replacement wisselt gelokaliseerde afbeeldingen per map, en Content Swaps wijzigt kleine secties HTML op één locatie. Vertalers zien de lay-out terwijl ze werken: het GDN legt automatisch visuele context vast voor HTML-inhoud, en voor de 33 rechts-naar-links locaties die Smartling lijsten, probeert de CAT Tool HTML-context van rechts naar links te renderen, waarbij Smartling opmerkt dat de live-pagina zelf nog steeds gebouwd moet worden om RTL correct te renderen.

Gerelateerde vragen

• Hoe ontwerp je een gebruiksvriendelijke meertalige website?
• Hoe beschermen proxy's voor websitevertaling meertalige SEO?
• Kunnen websitevertalingsproxies meertalige A/B-testen ondersteunen?
• Welke ontwerptools werken het beste voor RTL-lay-outs en lokalisatieworkflows?