CDN Strategy for Multilingual Websites: Edge Delivery, Vary Header, Geo-Routing

Basics of Multilingual Delivery in CDN

A CDN (Content Delivery Network) accelerates the delivery of your website by distributing static and dynamic content to edge servers in different regions. For multilingual websites, however, you must ensure that each user receives the correct language version – regardless of their location. The basic idea is that the CDN selects the language version based on signals such as the browser's Accept-Language header, IP geolocation, or a cookie preference, and delivers the right version from the cache or fetches it from the origin server.

In practice, you should first clearly identify your language versions. Use either different URL paths (e.g., example.com/de/), subdomains (de.example.com), or a country-specific domain (example.de). The CDN must account for this distinction in the cache key so that different language versions are not incorrectly treated as the same content. Therefore, configure a cache key in the CDN that includes the language or path in addition to the URL. Many CDNs allow specification of a custom cache key, for example by including the Accept-Language header.

A common challenge is dynamic language selection. If your website determines the language server-side based on cookies or session data, you must ensure that the CDN understands this dependency. Otherwise, a user might receive the version intended for a previous visitor. It is recommended to encode the language in the URL, as URLs are easiest to cache. If you use geo-routing, combine it with a fallback mechanism for users who prefer a different language.

Action recommendations: Choose a consistent URL structure per language and configure the CDN cache key to include the language information (e.g., via path or header). Test the behavior with different browser settings to ensure the correct version is delivered. Document your configuration to avoid future sources of error.

How Edge Delivery Works for Language Versions

Edge delivery means that content is served directly from the geographically closest edge servers without burdening the origin server. For multilingual websites, these edge servers must be able to correctly identify and deliver the requested language version. The idea is to move the language selection process as close to the user as possible – either via server-side logic in the CDN or through pre-generated static files per language.

In practice, it is advisable to generate separate static files for each language version and cache them on the edge servers. Your origin server creates the HTML pages for each language (e.g., via a build tool) and uploads them to the CDN. The edge server can then deliver the correct file based on the URL path or a cookie preference. No backend call is required, which drastically reduces latency. This method is particularly suitable for websites with predominantly static content, such as corporate sites or blogs.

Another variant is dynamic edge delivery, where the CDN makes language selection based on the Accept-Language header. This requires an edge function (e.g., Cloudflare Workers, Lambda@Edge) that evaluates the header and loads the corresponding version. This allows customized delivery but requires more configuration and can impact cache hit rates, as different headers lead to different cache entries. Combine dynamic logic with a careful cache key strategy.

Action recommendations: Use static pre-generation per language whenever possible and store the files in the CDN. If dynamic logic is necessary, implement an edge function that evaluates the Accept-Language header and loads the appropriate file. Set realistic cache durations and test latency with tools like WebPageTest to ensure fast delivery in all regions.

HTTP Vary Header: Configuration and Pitfalls

The HTTP Vary header is essential for multilingual websites because it informs the CDN and browsers which request headers influence the response content. Without correct Vary configuration, a language version might be delivered to a user even though they requested a different language. The Vary header prevents the CDN from mistakenly serving a response for one language version to users with a different language preference.

Set the Vary header at least to 'Accept-Language' if your website selects the language based on this header. Example: 'Vary: Accept-Language'. If additional cookies or other headers are relevant, list them as well, separated by commas. However, note that too broad a Vary configuration can reduce cache efficiency, as the CDN must store different versions for each combination of the specified headers. In practice, it has proven effective to specify only the actually relevant headers and to shift language selection to the URL as much as possible to minimize the use of Vary.

A common pitfall is using 'Vary: User-Agent' for language selection – this is usually incorrect and drastically reduces the cache hit rate. Omitting Vary altogether can also lead to inconsistent deliveries. Another mistake is setting the Vary header only on the origin server but not in the CDN. Many CDNs respect the origin's Vary header, but you should explicitly check this in the configuration. Use tools like 'curl -I' to verify that the header is sent correctly.

Recommendations: Always set the Vary header on the origin server to 'Accept-Language' (or extend it as needed). Check your CDN's cache key configuration – it must respect the Vary header, otherwise the header is ineffective. Test with different Accept-Language values to ensure the correct version is delivered. Avoid unnecessary Vary values that impair cache performance. For legal aspects of language selection (e.g., imprint obligation), please consult a lawyer.

Geo-Routing and DNS-based Language Control

Geo-Routing directs visitors based on their IP address to the nearest data center or edge server. This reduces latency because content is delivered from a geographically close location. For multilingual websites, the question arises whether geo-routing should also be used for language control. In practice, this is not recommended because geographic location alone does not reliably determine a language. In multilingual countries like Switzerland, Belgium, or Canada, users speak different languages. Pure geo-routing would always deliver the same language there, regardless of individual preferences.

Instead, you should primarily use geo-routing for performance optimization. Configure your CDN so that all language versions are delivered through the same distribution, but edge servers are selected based on the user's location. Language selection then occurs at the edge level through other mechanisms (e.g., Accept-Language header, cookie, or URL path). DNS-based geo-routing services like AWS Route53 with geolocation routing can be used to direct users from specific regions to different CDN endpoints. However, this is only useful if you operate separate origins for different regions – for example, to meet legal requirements or offer local content. For pure language control, this approach is too inflexible.

A proven configuration is to use a single CDN entry (e.g., CNAME to a CloudFront distribution) for all language versions and restrict geo-routing at the DNS service level to latency optimization (latency-based routing). The decision about which language version to deliver is made at the edge – either through an edge function that evaluates the Accept-Language header or through the URL structure (e.g., /de/ or /en/). Avoid assigning users to a specific language version solely based on their IP, as this leads to frustration and degrades the user experience.

In summary: Use geo-routing only for edge server location selection, not for language selection. Combine it with language-detection logic on the edge server or a URL-based language control. This ensures that content is delivered quickly and the correct language version is available for each user. For DNS-based control, we recommend a service that supports both latency and geolocation routing if specific regional requirements exist.

Cache Strategies for Dynamic and Static Content

Multilingual websites combine static content (such as translations, images, CSS) with dynamic content (personalized elements, shopping cart). Each component requires an adapted cache strategy to minimize load times and ensure freshness. Static assets should be assigned a long cache duration, as they rarely change. Use versioning in the filename (e.g., style.v2.css) and set the Cache-Control header to max-age=31536000 (one year). This enables aggressive caching at the CDN level and in the browser without complete invalidation when updating.<br><br>For HTML pages that differ per language, a URL-based language identifier (e.g., /de/produkt) is recommended. The cache key automatically includes the language, so the CDN stores separate copies for each language version. Set a moderate cache duration for these pages (e.g., 10–60 minutes) depending on update frequency. Use CDN purge mechanisms to selectively invalidate language versions when content changes. Avoid using the Accept-Language header in the cache key (via Vary), as this reduces cache hit rates. Instead, use the URL or a cookie that you incorporate into the cache key via an edge function.<br><br>Dynamic content such as personalized greetings or shopping cart data cannot be cached through the CDN. Here, using ESI (Edge Side Includes) or offloading these elements to asynchronous API calls is advisable. Many CDNs support ESI to dynamically assemble personalized fragments while the rest of the page content is served from cache. Alternatively, you can load these parts via client-side JavaScript. Another option is to use dynamic acceleration services that offer specific optimizations for non-cacheable content.<br><br>In practice, the following combination has proven effective: static assets with long cache duration and versioning; HTML pages with URL-based language version and moderate TTL; dynamic elements via ESI or asynchronous loading routines. Avoid using cookies for language selection if you want to cache the entire page – unless your CDN allows incorporating the cookie value into the cache key. Test cache behavior regularly with appropriate tools to ensure users always receive the latest language version without performance losses.

Language Detection at the Edge: Header, Cookie, URL Path

To deliver the appropriate language version to visitors, the CDN must determine the desired language. Three methods have become established: evaluating the Accept-Language header, a language cookie, or the URL structure (path or subdomain). Each method has advantages and disadvantages, especially regarding caching and SEO. The URL path (e.g., /de/startseite) is the most cache-friendly, as the CDN stores each URL as a separate entry and no Vary header is required. Disadvantage: The user must explicitly choose the language or be redirected by the server.<br><br>The Accept-Language header allows automatic detection without a cookie. However, using the Vary header (Accept-Language) in the CDN often leads to cache fragmentation, as each header value creates its own cache copy. Many CDNs support Vary only to a limited extent or ignore it altogether. Therefore, it is recommended to use the header only for the initial language detection and then redirect the user to a URL with a language path. This can be done via an edge function that reads the header, optionally sets a cookie, and performs a 302 redirect to /xx/.<br><br>A cookie provides persistent storage of the language preference, even across sessions. For CDNs that support a custom cache key based on cookies, this can be a solution. The cache key then contains the cookie value, so different languages are cached separately. Disadvantage: First-time visitors without a cookie must receive a default language (e.g., via Accept-Language), and the cache for visitors with cookies is less efficient because many different cookie values exist. This method is therefore more suitable for websites with few languages or when personalized language control is unavoidable.<br><br>Our recommendation for practice: Use the URL path as the primary language identifier. Implement an edge function (e.g., Lambda@Edge or CloudFront Functions) that, when a language path is missing, evaluates the Accept-Language header and redirects the user to the appropriate language URL. Optionally, set a cookie to skip manual selection on future visits. This combination is cache-friendly, SEO-compliant (clearly separated URLs), and provides a good user experience. Ensure that the redirect is short-lived or not cached at all so that it works correctly during language changes.

Handling Multilingual SEO and hreflang Tags

Hreflang tags are the central signal for search engines to communicate the linguistic and regional targeting of your pages. In a CDN environment, you must ensure these tags are correctly present on every delivered page. The most common methods are: - Integration in the HTML <header> via <link rel="alternate"> elements - Setting the HTTP Link header (e.g., Link: <https://example.com/de/>; rel="alternate"; hreflang="de") - Specification in the XML sitemap

In practice, each variant has advantages and disadvantages: The HTML approach is easy to implement but may not be fully adopted by some CDN caching layers if the page is dynamically generated. The HTTP header is more robust because it can be evaluated by the CDN independently of the HTML body. The sitemap serves discovery purposes, not page-level signaling – it alone is insufficient. We recommend setting hreflang both in HTML and as an HTTP header to safeguard against cache losses.

A common mistake is the lack of self-reference tags – each URL must include a hreflang entry for itself. Additionally, use the correct language encoding according to ISO 639-1 and, for regional variants (e.g., de-AT), observe the two-part structure. Ensure your CDN does not remove the hreflang headers from the response packet. Test with the Google Hreflang Test Tool or via Search Console to verify that all language variants are correctly recognized. A centralized configuration using an edge worker that dynamically adds hreflang headers based on the requested URL is a reliable solution in practice.

Recommendation: Conduct regular monitoring of hreflang signals, e.g., using crawling tools that check your CDN's output. Document your configuration in an internal playbook to avoid gaps during CDN changes or cache events. Note that hreflang is not a direct ranking signal but supports correct indexing of language versions.

Protection against false geolocation

Geolocation via IP address is error-prone: users with VPN, proxy, or mobile data sources may receive the wrong language version. CDN-specific geo databases can also be outdated or inaccurate. The result is an increased bounce rate when visitors see the wrong language. Therefore, multi-level protection is advisable.

A proven approach is to use geolocation only as an initial suggestion and always allow users to manually switch. Additional signals such as the browser's Accept-Language header or stored cookie preferences should always take precedence over Geo-IP. In the CDN configuration, you can use edge workers that evaluate these signals: For example, a worker first checks an existing language cookie, then the Accept-Language header, and only last the Geo-IP. Only if none of this information yields a clear language is Geo-IP used.

Another issue is cache isolation: If you serve different language versions on the same URL (e.g., via geo-routing without a URL path), cache poisoning can occur – a user from Germany suddenly sees the English version because the cache for the base URL was previously populated by a US visitor. Avoid this by including the language either as part of the URL (e.g., /de/) or as a query parameter, and set the Vary header accordingly. However, Vary: Accept-Language is difficult in practice because the header has many variants and cache hit rates decrease. Better: Vary: Cookie with a language cookie or Vary: X-Language for custom headers.

Recommendation: Provide a visible language switcher on every page and store the selection in a cookie for at least 24 hours. Test your geo logic regularly with a simulated proxy from different regions – use CDN-internal tests or external service providers. Document the decision cascade (Cookie > Header > Geo) in your codebase to ensure it is preserved during updates.

Performance metrics: latency, byte transfer, cache hit rate

To evaluate the effectiveness of your CDN strategy, three metrics are central: latency, transferred bytes, and cache hit rate. These should be captured both globally and per language version, as differences in content volume or regional CDN POP occupancy may occur.

Latency: Measure the time to first byte (TTFB) and total load time. For multilingual sites, latency is especially critical for dynamic language switches (e.g., via geo-routing). Use Real User Monitoring (RUM) to collect values from real user behavior—perception from different regions is crucial here. Pay attention to P95 and P99 values to identify outliers. Reduce latency through prefetching of language resources and persistent connections to the origin.

Transferred bytes: Depending on the language version, pages may vary in size—due to longer translations or different fonts. Optimize via CDN compression (Brotli or Gzip) and minimize egress data by server-side reduction of whitespace and metadata. Provider billing often depends on data volume served; a 20% reduction can noticeably lower costs. Compare byte counts of different language versions monthly and check whether CDN caching at the edge level applies equally to all languages.

Cache hit rate: A high hit rate (ideally above 90%) relieves the origin server and shortens response times. Multilingual sites complicate caching if each language version runs on its own URL with its own caching rules. Use consistent cache keys that correctly map language and region. Monitor whether certain language versions bypass the CDN to access the origin more frequently—this may indicate missing caching headers or too many individual parameters. Increase cache duration for static assets that are language-independent (e.g., JavaScript libraries) and use a cache-busting mechanism for changes.

Action recommendation: Set up a dashboard with these three metrics per language version. Set warning thresholds (e.g., TTFB > 500 ms for dynamic pages, cache hit rate < 85%). Conduct regular A/B tests where you vary caching rules or compression to improve performance. Document the results and adjust your CDN configuration iteratively.

Legal Aspects: GDPR-Compliant Localization at the Edge

Localizing content at the edge involves processing personal data, such as IP addresses for geolocation. According to the GDPR, this processing is only permissible with a legal basis. In practice, you should limit geolocation to what is necessary—for example, the regional level (federal state) often suffices to determine language without needing to store the exact address. We recommend processing IP data only in the memory of the CDN edge server and not logging or sharing it with third parties.

A common pitfall: storing user preferences via cookies. Use cookies that require consent for this purpose. Alternatively, use server-side cookies without tracking characteristics or URL paths (e.g., /de/). Ensure that language selection is not merged with other data (e.g., analytics) unless the user has actively consented. When using geo-routing, IP addresses are temporarily evaluated—according to many supervisory authorities, there is a legitimate interest here (Art. 6(1)(f) GDPR). Document this balancing of interests.

Practical implementation: Configure your CDN so that geolocation occurs without logging the IP. Use short-lived caches (e.g., 5 minutes) for the region-to-language mapping. Conclude a data processing agreement (DPA) with the CDN provider for processing. Check whether the CDN provider has server locations in the EU to avoid data transfers. For language delivery at the edge, consent is generally not required if you do not create profiles. However, seek legal advice to review the specific configuration of your setup.

Future developments: The draft ePrivacy Regulation could bring stricter rules for processing metadata. Therefore, plan for maximum data minimization from the outset. Regularly check whether your CDN provider offers GDPR-compliant localization functions (e.g., edge workers with data minimization). An annual data protection impact assessment for the localization component is recommended.

Implementation of a Multi-CDN Approach for Redundancy

A multi-CDN approach distributes the delivery of your multilingual content across multiple content delivery networks. This increases fault tolerance and can improve latency if a CDN fails regionally. In practice, this means using two or three CDN providers in parallel, either via a traffic distributor (e.g., DNS-based) or a failover strategy. For multilingual websites, this is particularly relevant because language versions may perform differently depending on the region.

Concrete implementation: Choose CDN providers with complementary edge locations (e.g., cloud provider A with strong presence in Western Europe, provider B in Eastern Europe). Configure DNS routing (e.g., via Anycast or GeoDNS) so that requests go to the optimal CDN based on region. Alternatively, use an application load balancer that forwards requests based on latency measurements. Important: All CDNs must serve the same origin content and deliver the language versions uniformly. Ensure synchronized cache configuration (Vary headers, TTLs).

Challenges: Different CDNs may handle Vary headers or language cookies differently. Therefore, test each language version on all CDNs. Use a unified cache invalidation mechanism: when you update a translation, you must purge cache tags across all providers simultaneously. In practice, a central cache management tool that sends purge requests to all CDNs in parallel has proven effective. In the event of a CDN outage, an automatic failover to a backup CDN should switch via DNS (shorten TTL) or client-side JavaScript (if SEO is not critical).

Cost aspects: Multi-CDN does not necessarily double costs because you can use traffic splitting. Negotiate volume discounts with providers. Pay attention to contractual data processing agreements (AVV) with each provider. Document failover processes and test them regularly (e.g., quarterly). A multi-CDN approach is especially recommended for business-critical multilingual portals aiming for 99.99% availability.

Integration with common CMS and translation management systems

The seamless integration of a CDN with your content management system (CMS) and translation management system (TMS) is the key to automated multilingual workflows. In practice, this means: your CMS generates separate URLs or a language slug for each language, the TMS delivers translated content, and the CDN serves it from the edge. We recommend modeling language versions as independent URLs (e.g., /de/, /fr/) because the CDN can then cache per path and the Vary header becomes less complex.

Concrete integration: Many CMS (such as WordPress, Drupal, Contentful) offer plugins or modules for multilingual output. These should tag content with hreflang tags and use a clear URL structure. The TMS (e.g., Smartling, Lokalise, memoQ) can push translations directly into the CMS via API. For CDN connectivity, it is crucial that the CMS or TMS controls cache invalidation – for example, via a webhook that sends a purge request to the CDN upon translation completion. In practice, it has proven effective to purge the cache for exactly that page and possibly parent navigation areas when publishing a new language version.

Challenges: Dynamic elements such as personalization or user profiles cannot be delivered purely from the edge. Use Edge Workers here that, for example, read the language from a cookie and make the corresponding CMS call. For static content (blog articles, product pages), we recommend fully pre-cached delivery. Ensure that your CMS sets locale corrections (e.g., date formats, currencies) server-side, as the CDN does not provide formatting logic. Test the integration in a staging environment with all components.

Best practice: Define a unified API endpoint for language content that your frontends and the CDN use. Use cache tags to jointly invalidate related resources (e.g., all pages of a language version). Document the workflow from translation request to delivery at the edge. Close collaboration between the development team, translators, and CDN administrator is essential. We recommend conducting regular reviews of cache hit rates per language to identify optimization potential.

Testing procedures and quality assurance for distributed content

Quality assurance for multilingual CDN-based websites requires specific testing procedures that cover both technical and linguistic aspects. A key element is testing the geo-routing logic: simulate accesses from various European countries using VPNs or the CDN's own testing tools. Verify that the correct language version is delivered by measuring both the HTTP status code and response time. For each target region, test at least three different locations to ensure consistency. Note that CDN edge nodes in neighboring countries may have different configurations depending on the provider – record the actual PoP locations for later error analysis.

Another focus is on the correct interpretation of the Vary header. Use tools like curl or specialized browser extensions to capture the headers sent. Ensure that your CDN includes the Vary header with relevant fields (e.g., Accept-Language, Cookie) and does not unnecessarily restrict it to content type or encoding. Perform load tests with different Accept-Language values to rule out cache poisoning. Repeat these tests after every cache setup or configuration change. Document all results in a central test matrix that will serve as a baseline for monitoring.

For dynamic content that is personalized or user-specific, a multi-stage approach is recommended: first test correct functionality without CDN (directly on the origin server), then with CDN enabled, and finally with geo-routing enabled. Pay attention to the cache hit rate: a low rate may indicate inefficient Vary headers or too short TTLs. Additionally, measure the delivery time for each language version – practical experience shows that latency differences of over 200 milliseconds between different regions can indicate suboptimal CDN configuration. Aggregate these metrics over at least one week to account for seasonal variations.

Finally, we recommend integrating an automated test script into your CI/CD pipeline. Regularly simulate requests for all relevant language combinations from various European regions, e.g., once daily. Include the results in a dashboard that also tracks the cache hit rate and the number of successfully delivered hreflang tags. Only through this combination of manual spot checks and automated checks can you ensure that your multilingual CDN strategy works reliably and SEO risks are minimized.

Checklist: Production Deployment and Monitoring

Before switching your multilingual CDN configuration to production, go through this checklist to avoid common mistakes. First, check that the Vary header is correctly set for each language version and that your CDN passes this header to the client – especially with HTTPS. Test geo-routing rules using at least five different locations in Europe; record latency values and compare them with your SLAs. Also ensure that your DNS configuration is consistent: CNAME entries should point to the correct CDN endpoints and not cause unnecessary redirects. Conduct a TTL audit: dynamic content should have shorter TTLs (seconds to minutes), while static JavaScript or CSS files should have longer lifetimes (hours to days).

Set up comprehensive monitoring that goes beyond pure availability. Measure actual latency per edge PoP and per language version – many CDNs offer APIs or third-party integrations for this. Watch for anomalies such as sudden increases in cache miss rate or unexpected response times. Record the thresholds you define as critical (e.g., latency over 1 second for main pages). Install synthetic monitors that regularly check the delivery of all language versions and alert on deviations. Document escalation paths for error cases, including those responsible for language quality and CDN configuration.

Another point is monitoring cache efficiency. Track hit rates per CDN PoP; values below 70% for static assets often indicate missing cache key optimization. Regularly check whether your CDN is actually caching content at the edge nodes or if pass-through modes are active that forward every request to the origin server. Set up an alerting system that notifies you when a PoP's hit rate falls below a defined threshold. Combine this data with your latency measurements to identify hotspots early.

Don't forget log management: enable access logs or real-time streams from your CDN and forward them to a SIEM or analysis tool. Pay special attention to 404 errors for localized pages – these may indicate missing translations or incorrect geo-routing rules. Schedule regular manual spot checks where a native speaker fully clicks through at least one language version every quarter. Only through a combination of automated monitoring and human review can you ensure a consistent, performant, and legally compliant multilingual website in production. Always have all legal aspects (GDPR, cookie notices) reviewed by your legal department – this guide does not replace legal advice.

Common Sources of Errors and Solutions in Multilingual CDN Implementations

When setting up a multilingual CDN, similar errors frequently occur in practice. A central issue is the incorrect configuration of the Vary header. If, for example, you only use the Accept-Language header but the Vary header does not cover all relevant criteria (such as URL path or cookie), the CDN may deliver the wrong language version. Therefore, always check that the Vary header matches the actual cache keys used. Another typical mistake is the lack of a fallback language. If a user comes from a region for which no dedicated language version exists, a default language (e.g., English) should be delivered – otherwise, you will receive empty pages or error messages. Geolocation is also error-prone: users browsing via VPN or near borders may get the wrong language version. It is advisable to provide a manual language switcher on the website and store the user's choice via a cookie. The interplay between hreflang tags and CDN geo-routing can also lead to conflicts. Ensure that the hreflang tags output in the HTML match the actual language version delivered, otherwise you signal inconsistent content to search engines. For troubleshooting, it helps to analyze the HTTP response headers of delivered pages – especially the cache headers, the Vary header, and any geo headers. Tools like curl with custom headers or browser-based developer tools are useful here. Document your configuration and perform regular tests with users from different regions. Note that errors in CDN configuration not only impair user experience but can also negatively impact search engine rankings. If in doubt, consult a CDN and localization expert – careful configuration saves a lot of effort later.

Tools and automation for managing multilingual content in the CDN

To operate a multilingual website with a CDN efficiently, you should rely on specialized tools and automation. A key element is a cache management tool that allows targeted invalidation of language versions. Many CDN providers offer APIs that let you clear the cache only for the affected paths when updating individual language pages – this avoids unnecessary cache resets for all language versions. For managing translations and their delivery, we recommend using a Translation Management System (TMS) that ideally offers direct integration with your CMS and CDN. This allows you to automatically deploy language versions from the TMS to the CDN and equip them with the correct headers. For monitoring delivery quality, use a synthetic testing tool that regularly simulates requests from different geo-regions and checks the delivered language version, load time, and header correctness. If you operate a multi-CDN setup, a traffic management tool such as Anycast DNS with health checks simplifies distribution across multiple providers. Ensure that your monitoring solution also tests language switching: simulate users who switch language via a cookie or URL parameter, and check whether the next request receives the correct variant. Additionally, you can set up CI/CD pipelines that automatically clear the cache for affected paths and reset HTTP headers with every translation update. All these tools require careful setup and regular maintenance. Plan sufficient time for initial configuration and train your staff in using the systems. Thoughtful automation reduces errors and relieves your team – but it does not replace manual quality control, especially when checking linguistic correctness and compliance with legal requirements.