Hello, this isKototsuki Design.
I’ve decided to expand a site that was originally operated in Japanese only to include English and German as well. At first, I thought it would be quite simple. I figured I’d just translate the Japanese text into English and German and add a language selector—that was all there was to it.
However, once I actually got started, it turned out not to be that simple. URL structure, managing translation data, machine translation, mistranslations of proper nouns, API rate limits, fonts, Google Analytics, cookie consent, GeoIP, GDPR, and legal requirements for Germany—before I knew it, it was no longer just a matter of “adding a translation feature,” but rather a complete overhaul of the site’s design.
Today, I’ll summarize what I did while actually implementing support for three languages—JA, EN, and DE—and highlight the points that were particularly challenging.
First, converting a Japanese-only site to a multilingual site
Naturally, the original site was built with Japanese as its sole language. When adding English and German, we first changed the site’s architecture itself from a “Japanese site” to a “multilingual site.”
For the URL structure, we opted for the subdomain method rather than the path prefix method (kototsuki.com/en/のような形).This structure keeps the Japanese content on the existing domain while separating the English and German content into subdomains. At first glance, this may seem like a minor change, but in reality, it requires managing information such as “What is the current language?” and “Where are the pages in other languages?” across the entire site. This goes far beyond simply tripling the amount of text.
How to Manage Translations
The next issue we faced was the translations themselves. While it’s possible to create all English and German pages manually, given the anticipated growth in content—such as blog posts and case studies—manually updating all three languages every time would be extremely difficult. Therefore, we developed a system that uses the DeepL API to automatically translate content during the build process.
The content subject to translation includes UI text, static pages, case studies, blog posts, and more. With this system, whenever content is added or modified on the site, the necessary translations are automatically generated.
Translating Everything Every Time Is a Waste of API Quotas
There was another issue here. If we sent all content to DeepL every time we built the site, even articles that hadn’t been changed would be translated each time. So, we implemented a system that saves a hash of the original text and compares it to the previous hash, re-translating only if there are differences.
It’s a simple if-else statement: if the hashes match, don’t translate; if they differ, re-translate using DeepL. Even if just a single character is changed in a blog post, only that post is re-translated, which has significantly reduced unnecessary API usage.
Dealing with DeepL’s 429 Error
As the number of items to translate increased, I began hitting the DeepL API’s rate limit. This resulted in an HTTP 429 error, meaning “Too Many Requests.” I implemented three countermeasures: retries, exponential backoff, and saving translated data in progress—but “saving in progress” proved to be the most effective.
Initially, the system was structured to write the cache only when the translation process completed successfully. With this approach, if a 429 error occurred on the 80th entry and the build failed, the results for all 80 entries translated up to that point would be lost as well. This meant having to start over from the beginning on the next build. So,try/finally, we modified the system to save the data translated up to that point to the cache, even if an error occurred midway. This really drove home the point that when automating a process, you need to consider not only what happens when it runs successfully but also what remains when it crashes partway through.
Machine Translation Corrupts Proper Nouns
Introducing machine translation also brought up another problem. The proper noun “Kototsuki Design” on our site was translated by DeepL as “Lake and Moon Design.” While this sounds natural as English, it’s problematic because it’s a proper noun.
So, I added a mechanism to exclude proper nouns from DeepL’s translation process.
What I learned from this is that even when using machine translation, it isn’t necessary to make everything fully automated. Leave ordinary text to the machine, and have humans handle proper nouns and important expressions. Setting up the system this way ultimately makes it easier to manage.
And, cleaning up past mistranslations
After implementing this system, another problem came to light. Data that had already been mistranslated in previous builds remained in the translation cache. There were 52 such instances.In the end, we detected and deleted the cache containing the incorrect translations, then re-translated the data using the correct rules. Just because you fix the code doesn’t mean all automatically generated data will be corrected automatically. If cached data or artifacts have already been generated, you need to include them in the migration as well.
After Translating, the UI Broke
Once the translations started working properly, issues with the screen layout began to appear—particularly with German. Compared to Japanese, German sentences tend to be longer, so the article titles in the breadcrumb trail became too long, causing the layout to break. To address this, we limited the display to 32 characters and retained the full titles in the HTML titleattribute.
This experience made me realize once again that multilingual support isn’t just about “translating strings,” but about “ensuring the UI remains functional even with the translated strings.”
Now, onto the main topic. Adding the German version brought up issues with the GDPR and German law
At this point, the discussion shifts slightly. By adding the German version, the likelihood of traffic from the EU—particularly Germany—realistically increased. We had to be mindful not only of Google Analytics and cookie handling but also of the legal disclosure requirements for providing digital services within Germany.
At this point, I needed to break down the relevant laws and consider them separately.
Although their names are often mentioned together, their roles are quite different. Let’s look at what each one refers to, one by one.
What Is the GDPR?
The GDPR (General Data Protection Regulation) is an EU law governing the processing of personal data and the rights of data subjects. Key issues include the use of external services like Google Analytics and the handling of personally identifiable information.
What Is the TDDDG?
The TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz) is a German law concerning the storage of and access to information on devices, such as cookies. While it overlaps with the GDPR, its focus is specifically on electronic communications and device data.
What is the DDG?
The DDG (Digitale-Dienste-Gesetz, or Digital Services Act) is a German regulation that requires providers of digital services to disclose information such as their name and contact details. Section 5 of the DDG stipulates that providers must continuously make this information—including the name, location, and contact details of the digital service in question—easily recognizable and directly accessible.
For convenience, we sometimes refer to them collectively as “GDPR/DDG compliance,” but in practice, we examined them as separate issues, one by one.
GDPR Compliance Is Determined by “Where the User Is Coming From”
The first issues that arose regarding GDPR compliance were Google Analytics and cookies. Our initial idea was to display a cookie banner only on German-language pages. However, this approach led to some inconsistencies, since users can view Japanese-language pages from Germany and German-language pages from Japan.
Therefore, we standardized the determination criteria based on “the visitor’s location” rather than “the page’s language.”if language == "de"Or rather,if visitor_country == "JP"This is the approach we took. This way, whether a user is viewing a German-language page from Japan or a Japanese-language page from Germany, they are treated according to the same standard.
If we visualize this, we can see that relying solely on language can lead to discrepancies—where the banner doesn’t appear when it should, or appears when it isn’t needed. By using the visitor’s location as the criterion, we’ve resolved this discrepancy.
To determine the visitor’s country, we use the existingprivate-analytics-appservergeoip-liteand/geoand created a new endpoint called [endpoint name].geoip-liteSince it uses a local database, there is no need to query an external GeoIP API.
This determination affects not only Analytics but also Google Fonts, the contact form, and the display of the privacy policy. To summarize, it looks like this.
A single GeoIP determination has led to four completely different implementations. When visualized in a diagram, it becomes clear that the impact was broader than we had anticipated. However, this is strictly the design adopted for this particular site. It does not mean that “Analytics can always be used in Japan without consent”; the actual applicability depends on the services used, the nature of the processing, and the circumstances of the business operator.
DDG’s Approach: Ensuring the Site Doesn’t Appear to Be an “Overseas Service”
Apart from GDPR compliance, launching a German-language site required us to consider how this site would appear to users in Germany. This service is intended for users within Japan. Nevertheless, by explaining the service details in three languages—Japanese, English, and German—and even presenting pricing plans, it could appear as though we were targeting users overseas, particularly within the EU.
Therefore, rather than simply translating the content, we adjusted the wording itself to make it clear who the service is intended for. This does not mean that DDG itself requires us to “hide the pricing plans on the German-language site.” Rather, the approach is to minimize, as much as possible from the website design perspective, any possibility that the service might be perceived as a digital service intended for the German market.
We also did not rely entirely on DeepL’s automatic translation for the “Service Areas” section on the homepage. For example, the phrase “Nationwide coverage” was manually adjusted not only to translate naturally into German but also to clearly convey that the service is intended for customers within Japan. Additionally, we added a note stating that this service is intended for customers in Japan and is not intended for customers overseas.We were mindful of this distinction—that being readable in German is not the same as targeting the German market—in every single piece of text.
The Final Result
To summarize the final structure roughly, it took the form shown above. What was intended to be a simple three-language site ended up incorporating multilingual URLs, a translation pipeline, translation caching,change detection, API retries, proper noun handling, multilingual UI support, GeoIP, cookie consent, analytics control, self-hosted fonts, region-specific content, tailored privacy policies, and even a review of the business information and service descriptions for the German market.
The most challenging part, surprisingly, wasn’t the “translation” itself
What struck me most from this experience is that multilingual support isn’t just about adding a translation feature. At first, I thought it would simply be a matter of translating Japanese into English and German. In reality, the scope of the work kept expanding.
What left the strongest impression on me was how a technical change—simply “adding a German version”—ultimately led to a business and legal discussion about “who this site is intended for.”
What I Learned from Building a Multilingual Site
I’ve summarized a few lessons learned from this project below.
- Plan for N languages from the start — Instead of implementing ja, en, and de separately, design the site to handle N languages from the beginning. This prevents having to rebuild the site when the number of languages increases from three to four or five.
- Don’t make machine translation “fully automated”—While DeepL is quite convenient, it doesn’t always handle proper nouns correctly. It was crucial to maintain a system where humans could manually review service names, company names, legal terminology, and expressions related to countries or regions.
- Always review the UI after translation — Strings that fit within the character limit in Japanese often overflow in English or German. It’s essential to check not only whether the translation is correct but also whether the UI remains intact after translation.
- Don’t base GDPR compliance on “whether the page is in German” — In this implementation, we based compliance on the visitor’s location rather than the page’s language. This is because some people view Japanese pages from Germany, while others view German pages from Japan.
- Don’t lump GDPR, TDDDG, and DDG together—a simple statement like “It’s a site for Germany, so it’s GDPR-compliant” doesn’t clarify exactly what compliance measures are in place.Protection of personal data, storage and access on devices, and the provider’s obligation to provide information. Since each involves different issues, it’s easier to organize the implementation if you consider separately which laws and requirements this compliance addresses.
- Legal and Technical Aspects Are Surprisingly Close — Ultimately, we had to consider not only which languages to display but also who the service appeared to be targeting. On multilingual sites, technical implementation, on-site messaging, and legal requirements are quite closely intertwined.
Frequently Asked Questions About Multilingual Support and the GDPR
Q. Is GDPR compliance mandatory when creating a multilingual website? Adding a
language does not, in and of itself, impose a compliance obligation. However, adding languages used within the EU—such as German or French—is likely to increase traffic from the EU. If your site uses systems that handle personal data (such as analytics tools or external services), you’ll need to consider measures based on the visitor’s location.
Q. Which is better for SEO: the subdomain method or the path prefix method?
Both methods have a proven track record. The main difference is that subdomains (en.example.com) make it easier to separate server settings by language, while path prefixes (example.com/en/) make it easier to consolidate domain authority into a single domain.In this case, we chose the subdomain method to prioritize simplicity in server configuration.
Q. How can I avoid the DeepL API rate limit (429 error)?
In addition to retries and exponential backoff, a mechanism that saves the translation results up to that point in the cache—even if the process fails midway—proved effective. For sites with high translation volumes, it’s safer to design the system with 429 errors as a given.
Q. Do GDPR, DDG, and TDDDG each require separate compliance measures?
Since these address different issues, it’s easier to prevent implementation oversights by reviewing them separately—handling personal data (GDPR), handling device data such as cookies (TDDDG), and the obligation to provide business information (DDG)—rather than treating them collectively as a single compliance measure.
Q. I’m concerned about the accuracy of visitor location detection (GeoIP). How do you handle this?
In this case, we designed the system so that if a location can be determined, processing is tailored accordingly; if it cannot be determined, we err on the side of caution and make cookie consent mandatory. The key is to ensure the configuration does not rely entirely on the accuracy of GeoIP detection.
Summary
This multilingualization project started out as a small change: “adding English and German.” However, it actually became an opportunity to review the entire site.
We automated the translation process using the DeepL API and implemented a system that combines change detection, caching, and retry mechanisms for operational efficiency. At the same time, we needed a mechanism to manually control proper nouns and critical expressions rather than leaving them to machine translation.Furthermore, the addition of the German version prompted us to implement GDPR-compliant cookie consent, region detection via GeoIP, self-hosted Google Fonts, and region-specific content display. In addition to the GDPR, we also had to consider Germany’s Digital Services Act (DDG) and the Teledienstdatenschutzgesetz (TDDDG)—which pertains to cookies—as separate issues.
As a result, the project evolved from simply “making the site trilingual” to “rebuilding the site so it can be operated in three languages.” I hope this serves as a helpful reference for anyone looking to get started with multilingual support.
Contact Form 
Related Articles 
